era eriksson <era(_at_)iki(_dot_)fi> writes:
...
However, tangentially, I noticed something funny here:
$ cat moo.rc
SHELL=/bin/sh
UMASK=022
MAILDIR=.
DEFAULT=oops
VERBOSE=yes
:0:
foobar
...
$ ls -l foobar
-rw-r--r-x 1 reriksso system 2962 Sep 10 13:14 foobar
^ ^
Is there a bug in Procmail's umask handling?
That's a feature, not a bug! To quote the procmailrc(5) manpage:
UMASK The name says it all (if it doesn't, then forget
about this one :-). Anything assigned to UMASK
is taken as an octal number. If not specified,
the umask defaults to 077. If the umask permits
o+x, all the mailboxes procmail delivers to
directly will receive an o+x mode change. This
can be used to check if new mail arrived.
Anyhow, normally, under Unix, the creat system call will set default
permissions of 666 and the umask can only be used to mask off the bits
you don't want (and not to e.g. add x bits). Shouldn't Procmail work
this way, too, just to be consistent with the rest of the system?
creat() will set the permissions to whatever you want it to, modulus
the umask. If the umask is zero, you can set the permissions to 7777,
though that would be kind of stupid (and actually, most versions of
UNIX won't let you set both the sticky bit and an executable bit unless
you're root, for historical reasons). Most programs that call creat()
or open(..,O_CREAT,...) give a mode argument of 0666, as they generally
don't write out executables. Procmail just happens to call open() with
a mode argument of 0667, to be modified by your umask.
Philip Guenther