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


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.  In theory postsuper should just use the
account it's running under on Cygwin.  Is that not possible?

> >> 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.  That's going away when switching to 1.7.34...

> >> [...]
> >> If csih_use_file_etc returns false, all the script could do for now is
> >> to refuse the creation of local users or groups.
> > No.  If `csih_use_file_etc group' fails, don't write the newly created
> > group to /etc/group.  Otherwise do.
> 
> Does not work in the 'member of a domain' case, because then the created
> Cygwin group has the form HOST+GROUPNAME. The group name in the configuration
> file needs to be fixed then.

Yes?  Why can't you just ask for the cygwin name using getent, for
instance,

  getent group $group_name $COMPUTERNAME+$group_name | head -1

> Therefore some csih_create_local_group function would be useful.

Sure, but it doesn't exist right now.

> >> The (files-only|non-domain|domain) complexity should be handled in csih,
> >> IMO:
> > Uhm... AFAICS it is.  After checking or creating a user, the new incarnation
> > of csih will have set three variables, either
> >
> >    csih_PRIVILEGED_USERNAME
> >    csih_PRIVILEGED_USERWINNAME
> >    csih_PRIVILEGED_USERDOMAIN
> >
> > or
> >
> >    csih_UNPRIVILEGED_USERNAME
> >    csih_UNPRIVILEGED_USERWINNAME
> >    csih_UNPRIVILEGED_USERDOMAIN
> >
> > so the calling script can just use the new name in whatever variation
> > required.
> 
> Sounds good.
> 
> How will the username input parameter be interpreted?
> Cygwin name, Windows name or depending on an option?

Cygwin name in the first place, unless the account doesn't exist.
In that case the mapping doesn't exist either, so it will be treated
as Windows name and the mapping will be generated on the fly.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpgDyRnWV3lQ.pgp
Description: PGP signature


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