Kevin D <kdlists(_at_)mtsolutions(_dot_)net> writes:
Is any directory in the path from / to the rcfile group-writable or other-
writable?
Unlike the checks that sendmail does when opening .forward and alias
files, procmail only checks the file itself and the directory that it
is in.
Here's the entire path to the user directory:
/home/sites/www.mtsolutions.net/users/kdemello
home - rwxr-xr-x
sites - rwxr-xr-x
www.mtsolutions.net - rwxrwsr-x
users - rwxrwsr-x
kdemello - rwxrwx--- (i've been playing with permissions on this) (owner
kdemello, group is not primary group for kdemello)
As mentioned in previous message, group writability is only allowed when
it's the user's primary group.
The whole idea of procmail's permission and ownership checks is that it
will not trust an rcfile that someone else can change, either by directly
writing to it or by renaming inside the directory itself. When the checks
were initially tightened up during the 3.12 development, procmail would
*never* trust a group writable file or directory. After all, the whole
point of a 'group' is that there can be more than one user in it, no?
This ran into a snag: some OS distributions (RedHat Linux, OpenBSD, and
others) give each user their own group as their primary group (i.e.,
the group listed in their password file entry). They then set the
user's umask to 002, so that new files and directories are by default
group writable**. Since the user's .procmailrc and $HOME are then both
group writable, procmail didn't trust them. Thus the GROUP_PER_USER
compile-time flag was added: the person who installs procmail can tell
procmail that each user's primary group is to be considered 'trusted'.
The presumption is that the installer will only do this when, for every
user "foo", "foo" is the only user in "foo"s primary group.
If you want a process to be able to change users' rcfiles, run it as root.
Any process that can do that can almost certainly obtain root access by
running commands as individual users through their rcfiles. You might
as well give it root directly and then watch it like a hawk.
As a case study, consider the "bin" account: it used to be that almost all
the files in /bin, /usr/bin, and /usr/lib were owned by the "bin" user.
Someone finally realized that if someone could break into the bin account,
he or she could change any of the files in, say, /usr/bin such that when
executed by root (say, during a reboot), a setuid root shell would be
dropped in some directory like /tmp. Therefore, having privileges of
"bin" are effectively the same as "root". Furthermore, "bin" is not
'protected' like the root account is (for example, "root" privileges
are not exported over NFS by default; "bin" has no such protection).
Once that was realized, OS vendors quickly changed all those files and
directories to be owned and only writable by root. The only user that
root should have to trust is itself.
** Why do that, you ask? Having a default umask of 022 makes it
difficult to share file using groups (I had to deal with this on a
seemingly continual basis at my previous job, as people regularly edited
'group' files and left them unwritable to anyone else in the group).
So, we want everyone's umask to allow group writability. That implies
that their primary group cannot be shared with anyone else, as otherwise
all their files would be editable by someone else by default. Yes,
you can always change the permissions with chmod, but 99% of the time,
the default results will remain unchanged, even if they're wrong.
Extra effort needed => won't get done.
Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail