[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
Tue Nov 11 11:37:00 GMT 2014
On Nov 11 07:39, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Nov 10 20:21, Christian Franke wrote:
> >>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 ]
I'm making the prefixing depend on the just running Cygwin version
right now, and then, if an nsswitch.conf file exists, whether the
setting is "files"-only or not.
> >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
> username match.
> For the long term, have some cyguser, cyggroup tools (similar to cygpath)
> which convert the names would be helpful.
Feel free to provide them. I'm not quite sure what kind of conversion
you're thinking about. Cygwin->Windows? If so, you can get that
with simple scripts:
pwd_entry=$(/usr/bin/getent passwd "$username")
# Extract Windows username and domain
> > 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
That's an interesting idea...
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin