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 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.

The postfix master running as service under cyg_server is not affected
of course.


>>> - The script still accesses /etc/group and /etc/passwd, but it should
>>>     not.  For reading there's getent available for quite some time now.
>>>     Creating accounts in /etc/passwd and /etc/group should depend on the
>>>     Cygwin version.
>> /etc/passwd is not accessed.
> Sorry, I misread /usr/bin/passwd as /etc/passwd :}
>
>> 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})


>> The other /etc/group modifications were only added because csih lacks a
>> csih_create_local_group function.
> Well, ok, but it shouldn't add to /etc/group invariably.
>
>>>     I prepared a matching function for testing this in
>>>     csih, which looks like this:
>>>
>>> # Routine: csih_use_file_etc passwd|group
>>> #   Check if /etc/passwd or /etc/group file is in use.
>>> #   On Cygwin versions < 1.7.33, files are always used.
>>> #   On Cygwin versions >= 1.7.33 it depends on /etc/nsswitch.conf.
>>> ...
>>> csih_use_file_etc()
>>> {
>>> ...
>>> } # === End of csih_use_file_etc() === #
>>> readonly -f csih_use_file_etc
>>>
>>>     Maybe you could just copy the method for now until I get my lazy
>>>     back to finish the work on csih?
>> OK.
>>
>> 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.

Therefore some csih_create_local_group function would be useful.


>> 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?

Thanks,
Christian




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