[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6

[Corinna Vinschen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20141111/da85eb9c/attachment.sig>