open() throws permission error and I don't get why

[Nobody]

On Fri, 15 Oct 2010 10:52:53 -0500, Andy Theuninck wrote:

> I'm trying to write a script to read e-mail over stdin, extract
> attachments, and distribute them around the file system based on the
> incoming e-mail address.
> 
> Everything works until I actually try writing interesting file system
> locations.
> 
> I've established, through logging, that postfix runs my script with UID
> nobody & GID nobody. The directory I'm attempting to write has
> permissions 0770. The directory's group is not nobody, but the user
> nobody is a member of the relevant group. Nevertheless, python throws an
> IOError when I try to create a file there.
> 
> The issue seems to be isolated to python. I can run: sudo -u nobody
> touch DIRECTORY_IN_QUESTION/test and that creates a file.
> 
> Any ideas?

I suspect that postfix is only setting the UID and the (primary) GID,
but not the supplementary GIDs. In which case, it doesn't matter whether
"nobody" is a member of the group.

The /etc/group file (or wherever your system gets data for getgrent(),
which might include NIS, LDAP, etc) only matters insofar as programs pay
attention to it. Typically, programs which perform a "login" use the UID
and GID from /etc/password to set the UID and GID (via setuid() and
setgid()), and the information from /etc/group to set the supplementary
GIDs (via initgroups() or setgroups()).

The permission checks performed by the kernel use the EUID, EGID and/or
supplementary GIDs. They do not read /etc/passwd, /etc/group or similar.

OTOH, sudo probably /is/ setting the supplementary GIDs, which would
explain why sudo...touch works.

If my suspicions are correct, you may be able to get around the problem by
executing the script via "sg" (provided that it's installed; it's part of
the "shadow" package; "sg" itself should be a symlink to "newgrp").