This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] postfix 2.11.3


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]