[ITP] postfix 2.11.3

[Christian Franke]

Corinna Vinschen wrote:
> On Nov 17 15:50, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> On Nov 17 14:00, Christian Franke wrote:
>>>>>      Also, is
>>>>>      passwd -R really required?  This is typically no necessary, unless you
>>>>>      potentially have to do stuff with native Windows tools (cron, sshd
>>>>>      session).  Postfix doesn't seem to be a candidate for that.
>>>> For example the postsuper admin tool always drops root permissions by
>>>> setuid/gid() to $mail_owner ('postfix') before doing anything interesting.
>>>> (postfix never uses chown(), BTW).
>>>>
>>>> Could this really be done without passwd -R or cyglsa ?
>>> Usually, yes.  As a Cygwin tool without accessing native Windows
>>> functionality, it should not have a problem using
>>> https://cygwin.com/preliminary-ug/ntsec.html#ntsec-nopasswd1, unless
>>> it has to access network drives.
>> Does not work for me when running e.g. /usr/sbin/postsuper from any
>> admin user. The local admin group normally does not provide
>> SeCreateTokenPrivilege, at least on Win 7.
> postsuper switches the user account?  Where to?  From the command line
> that's obviously a problem.

See above (It always switches to $mail_owner and does never use chown()).

 From postsuper.c:

    * All file/directory updates must be done as the mail system owner. This
    * is because Postfix daemons manipulate the queue with those same
    * privileges, so directories must be created with the right ownership.


>    In theory postsuper should just use the
> account it's running under on Cygwin.

In (upstream) theory & practice, it should run with least privileges, 
which is good :-)


>    Is that not possible?

I did not try that yet. It may work for those cases where only files are 
removed and renamed. Repairing the spool directory would likely not work.


>>>> Yes, the first group 0 check should be replaced by getent, yes.
>>> Oh, hey, group 0 won't exist in a db-only scenario.  When testing for
>>> the admins group, check for gid 544, or SID S-1-5-32-544 using getent.
>> The check only ensures that group 0 does NOT exist because this would
>> break the internal uid mapping "root" <> "root equivalent"
>> (0 <> {18, 544, cyg_server or current_admin})
> Uh, that's a problem for now since base-passwd still creates a root
> group.

Oh yes, I forgot. I removed these entries long ago. I try whether it 
also would work with the root entries.


>    That's going away when switching to 1.7.34...

Then it should possibly be no problem if postfix relies on non-existing 
id 0 entries.

Christian