From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <13426df10706022014k240d2a96h12dea0548fa6a093@mail.gmail.com>
Date: Sat,  2 Jun 2007 20:14:38 -0700
From: "ron minnich" <rminnich@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [9fans] my previous note on vf
Topicbox-Message-UUID: 77a27cca-ead2-11e9-9d60-3106f5b1d025

Well, all my unhappiness with vf still applies but is now x2.

So, the real problem with the failed mail w/pictures is this from what
I can now tell:

error+ failed with error 'error creating temporary file:
'/tmp/vf.00000037245' permission denied
error+ rc: note: mail refused: we don't accept executable attachments
error+ '.
error+ The mailer `/mail/lib/qmail 'mbgokhale.org!maya' 'net!$smtp''
returned error status 72.
error+
error+

The path is this (do a src vf):
/*
 * Run the external checker to do content-based checks.
 */
static int
runchecker(Part *p)
{
	int pid;
	char *name;
	Waitmsg *w;

	if(access("/mail/lib/validateattachment", AEXEC) < 0)
		return 0;

	name = savetmp(p);
	fprint(2, "run checker %s\n",
.
.
.

savetmp does this:
static char*
savetmp(Part *p)
{
	char buf[40], *name;
	int fd;

	strcpy(buf, "/tmp/vf.XXXXXXXXXXX");
	name = mktemp(buf);
	if((fd = create(name, OWRITE|OEXCL, 0666)) < 0){
		fprint(2, "error creating temporary file: %r\n");
		refuse();
	}

note the failure path, which is refuse, which does this:
void
refuse(void)
{
	postnote(PNGROUP, getpid(), "mail refused: we don't accept executable
attachments");
	exits("mail refused: we don't accept executable attachments");
}

In other words, the return error in this case is pretty seriously
bogus. A tmp file create fails, which translates to a 'we don't take
that attachment type'. To say the least, this leaves the poor Mac user
in the dark.

It seems the temporary file create really does fail, but the error
returned is utterly wrong: it has nothing to do with executable
attachments.

Now it seems that I've hit something I had not had to think about before.
Listen is started up in /rc/bin/cpurc. It does a becomenone(). So
where can listen
open a /tmp file? Does /usr/bootes/tmp need to be 777?
In other words, how can this script,

#!/bin/rc
#smtp serv net incalldir user

user=`{cat /dev/user}
exec upas/smtpd -n $3

running as user 'none', ever spawn a process which can open a tmp
file? Where is /tmp for none anyway?

Thanks

ron