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 > >then. > > > >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 > >account. > > > >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, ... > fu > > 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.
Oh, cool!
> 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
tmp="${pwd_entry#*:*:*:*U-}"
tmp="${pwd_entry%%,*}"
domain="${tmp%\\*}"
username="${tmp#*\\}"
> > Alternatively, is setting some environment
> >variable feasible for tweaking the output of mkpasswd backward
> >compatible?
>
> 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp9at1hexRqe.pgp
Description: PGP signature
