[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
Tue Nov 11 06:39:00 GMT 2014
Corinna Vinschen wrote:
> On Nov 10 20:21, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> On Nov 7 21:51, Christian Franke wrote:
>>>> Corinna Vinschen wrote:
>>>>>>> In theory there should be only one option -l [machine], which prints the
>>>>>>> local accounts of the current machine unprefixed (standalone machine) or
>>>>>>> prefixed (domain machine), and always prefixed for a foreign machine.
>>>>>>> The -L option can just go away.
>>>>>> I disgree.
>>>>>> Why not keep the old behavior of -l/-L for user names of current machine for
>>>>>> those uses cases which rely on it?
>>>>> You are always free to change the passwd/group files manually:
>>>>> $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd
>>>> Of course, and it is good that this is still possible. But this would
>>>> require that all existing scripts relying on old behavior need to be
>>>> I still don't understand why this backward compatibility break of "mkpasswd
>>>> -l" was mandatory.
>>>> Most *-config scripts using "mkpasswd -l -u USER" may need to be changed.
>>> Definitely. The change is inevitable since most scripts using mkpasswd
>>> or mkgroup do so to create entries in /etc/passwd and /etc/group. But
>>> this doesn't make sense anymore, or if so, only marginally so.
>> What will be the behavior of the predecessor of e.g. the csih function
>> csih_create_unprivileged_user if called with USER without HOST prefix,
>> machine is inside of domain and the user does not exist:
>> - create local windows USER and require the config script to retrieve the
>> actual Cygwin HOST+USER name,
>> - fail and tell the calling config script to retry with HOST+USER instead
>> (if possible),
>> - create local windows USER and create a /etc/passwd entry to support a
>> non-prefixed Cygwin USER in this case,
>> - one of the above, selected by a new option.
> I'm not exactly sure yet. I'm working on it, and I ripped apart the
> functions dealing with this problem by handling the cygwin username and
> the windows username separately. But it's not yet finished. In theory
> you have two cases.
> Either the account already exists, then the user should (probably
> (grain/salt)) specify the Cygwin username, which is either prefixed or
> not prefixed, dependent on the DB it will get taken from. The script
> fetches the Windows domain and username from the U-... entry in pw_gecos
> Or the account doesn't exist, then the username is just a name. The
> user account will be created in the local SAM and dependent on the state
> of the machine, AD member or not, will be prefixed or not as Cygwin
> Something like that.
Possibly a two step process:
csih_check_unprivileged_user --allow-prefix $USER
if [ "$csih_unpriv_cygwin_username" != "$USER ]; then
# Cygwin username has prefix
.... inform user, patch configuration file, ...
csih_create_unprivileged_user [ $PASSWORD ]
>>>> Local scripts from Cygwin users which use "mkpasswd -l" may need to be
>>> They are not supposed to use mkpasswd anymore since they don't need it,
>>> only in very special circumstances.
>> Wouldn't it be better to let mkpasswd -l simply fail with an explanatory
>> error message instead of producing non-backward compatible results? Or at
>> least print a warning to stderr?
> But there still are cases in which using mkpasswd -l may be used. If
> somebody explicitely chooses to use "passwd: files"-only, then the
> mkpasswd tool needs to generate accounts.
> Is there any compromise possible which lets mkpasswd generate the
> forward compatible accounts by default? I made the change to mkpasswd
> and mkgroup I outlined last week, but I deliberately didn't check it in
> because I'm still hoping we find a compromise going forward. I
> understand that in your scenario you will have to use /etc/passwd for a
> while longer.
> But... how many scripts would you really have to change if mkpasswd
> generates prefixed names?
We could add 'sed' to /etc/passwd generating script, no problem.
The actual test scripts & tools from this use case pass local usernames
from/to non-Cygwin programs and rely on the fact that Cygwin and Windows
For the long term, have some cyguser, cyggroup tools (similar to
cygpath) which convert the names would be helpful.
> Alternatively, is setting some environment
> variable feasible for tweaking the output of mkpasswd backward
Of course, yes.
Or mkpasswd -l behavior depends on nsswitch.conf setting:
passwd only: Old behavior
passwd, db: New behavior, print warning
db only: fail
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin