This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6


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
changed.

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.
OK.

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 ]



Local scripts from Cygwin users which use "mkpasswd -l" may need to be
changed.
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 username match.

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
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

Christian


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]