This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] postfix 2.11.3
- From: "Christian Franke" <Christian dot Franke at t-online dot de>
- To: "cygwin-apps at cygwin dot com" <cygwin-apps at cygwin dot com>
- Date: Mon, 17 Nov 2014 15:50:30 +0100
- Subject: Re: [ITP] postfix 2.11.3
- Authentication-results: sourceware.org; auth=none
- References: <20141117135247 dot GJ3151 at calimero dot vinschen dot de>
- Reply-to: "Christian Franke" <Christian dot Franke at t-online dot de>
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