headers
Dimitri Maziuk | 13 Oct 2011 19:06
Picon
Favicon

gid problem

Hi everyone,

I've a simple mail processing script set up as follows:
- a user, say mailproc:mygroup, has its .mailfilter end with
to "| ~/.script.py"
- script.py saves the message to a file on a shared drive that real
users will use later on,
- in order for this to work, the files are group-writable by "mygroup"
and real users are members of mygroup,
- maildrop is the local delivery agent for postfix, master.cf has
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=daemon argv=/usr/bin/maildrop -d ${recipient}

This works fine of fedora 8 which has maildrop-2.0.4 installed suid/sgid
root:mail.

On centos 6 script.py fails with permission denied when trying to open
output file for append. Centos 6 has maildrop-2.5.0 (ATrpms build), also
suid/sgid root:mail.

Logging os.getuid() and os.getgroups() from the script results in
"mailproc:mygroup" on fedora 8 and in "mailproc:mail" on centos 6. The
script works from command line on centos and "groups" returns "mygroup".

So it looks like maildrop-2.0.4 on fedora changes its uid and gid to
those of the user specified in "-d" whereas 2.5.0 on centos changes only
its uid but not gid.

Was that a deliberate change in maildrop?
(Continue reading)

Permalink | Reply |
headers
Sam Varshavchik | 14 Oct 2011 01:58
Gravatar

Re: gid problem

Dimitri Maziuk writes:

> Hi everyone,
>
> I've a simple mail processing script set up as follows:
> - a user, say mailproc:mygroup, has its .mailfilter end with
> to "| ~/.script.py"
> - script.py saves the message to a file on a shared drive that real
> users will use later on,
> - in order for this to work, the files are group-writable by "mygroup"
> and real users are members of mygroup,
> - maildrop is the local delivery agent for postfix, master.cf has
> maildrop  unix  -       n       n       -       -       pipe
>   flags=DRhu user=daemon argv=/usr/bin/maildrop -d ${recipient}
>
> This works fine of fedora 8 which has maildrop-2.0.4 installed suid/sgid
> root:mail.
>
> On centos 6 script.py fails with permission denied when trying to open
> output file for append. Centos 6 has maildrop-2.5.0 (ATrpms build), also
> suid/sgid root:mail.
>
> Logging os.getuid() and os.getgroups() from the script results in
> "mailproc:mygroup" on fedora 8 and in "mailproc:mail" on centos 6. The
> script works from command line on centos and "groups" returns "mygroup".
>
> So it looks like maildrop-2.0.4 on fedora changes its uid and gid to
> those of the user specified in "-d" whereas 2.5.0 on centos changes only
> its uid but not gid.
>
(Continue reading)

Permalink | Reply |
headers
Dimitri Maziuk | 14 Oct 2011 16:17
Picon
Favicon

Re: gid problem

On 10/13/2011 6:58 PM, Sam Varshavchik wrote:
> Dimitri Maziuk writes:
>
... 2.5.0 on centos changes only its uid but not gid.

> This is a configurable compile-time option, that depends on the system
> configuration.

Thanks, I'll file a bug w/ ATrpms.

Dima

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
Permalink | Reply |
headers
Dimitri Maziuk | 14 Oct 2011 23:33
Picon
Favicon

Re: gid problem


(Sigh...) apologies for the noise.

I finally got around to reading more of the fine documentation and
checking all the permissions and generated config.h (using 2.5.4).

It looks like fedora and its derivatives set /var/spool/mail (and mbox
files in it) to g+w mail w/o the sticky bit. According to INSTALL,
"#define RESET_GID 0" in maildrop/config.h will let maildrop create mbox
files in the mail spool.

So I can see why Fedora may want to keep this setting and sgid bit on
the binary.

According to UPGRADE, in this setup with maildrop-2.4 or later
"processes started by maildrop will run using the [...] group id" that
owns maildrop binary.

None of this really tells me why a process started by maildrop as user
foo who is a member of the group bar can't append to existing file
group-writable by bar, but at this point I'm not sure I want to know.

I'm rewriting my mail processor script in a compiled language so that I
can run it suid/sgid and leave glibc, fedora, redhat, maildrop, and
whoever else's involved to their own devices.

Thanks Sam for pointing me in the right direction
--

-- 
Dimitri Maziuk
Programmer/sysadmin
(Continue reading)

Permalink | Reply |
headers
Dimitri Maziuk | 14 Oct 2011 19:57
Picon
Favicon

Re: gid problem

On 10/13/2011 06:58 PM, Sam Varshavchik wrote:

> This is a configurable compile-time option, that depends on the system
> configuration.
> 
> The default option is set by whether or not your traditional mbox spool
> directory has the sticky bit set, or not. Also whether maildrop is built
> from the standalone tarball or as part of Courier.
> 
> So the answer is, this is how your maildrop package was configured, when
> it was built.

I'm looking at 2.5.4 standalone tarball, could you tell me which option
that is?

UPGRADE file has the "You are impacted by this change if" bit, but I
don't see anything about getting the old behaviour back.

Nothing in "./configure --help" looks like it could possibly be remotely
relevant. Am I missing something?

I don't use mbox spool directory (maildirs here), so should I just chmod
/var/spool/mail? Or is there a define to set in makefile.in or some .h?

--

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
(Continue reading)

Permalink | Reply |
headers
Sam Varshavchik | 15 Oct 2011 00:24
Gravatar

Re: gid problem

Dimitri Maziuk writes:

> UPGRADE file has the "You are impacted by this change if" bit, but I
> don't see anything about getting the old behaviour back.
>
> Nothing in "./configure --help" looks like it could possibly be remotely
> relevant. Am I missing something?

Nope. maildrop's got some lineage going back years, and from the start it  
took the approach of guessing everything, and if it gets it wrong, you get  
to fix the #defines post-configure. Note this comment in INSTALL:

   The configure script creates Makefile, and config.h. After running
   configure, you may want to edit xconfig.h, and config.h in order to make
   minor adjustments to the configuration.

This is referring to config.h and xconfig.h in the maildrop subdir, and the  
option you're looking at is RESET_GID.


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Courier-maildrop mailing list
(Continue reading)

Permalink | Reply |
headers
Dimitri Maziuk | 14 Oct 2011 20:23
Picon
Favicon

Re: gid problem


On second thought, what are the implications of not having sgid on
maildrop binary? Is that going to affect anything other than delivery to
mbox files?

--

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Courier-maildrop mailing list
Courier-maildrop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/courier-maildrop
Permalink | Reply |

Gmane