X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=kAlHq/zcAtvayc703n3iAtBYDAhifVVg8OJU7PoyxY4yAqfJmaEcy
	RLbPzvAjQC3lJ9cPfbja5q6Zr0/XVsINuvLYNGwoVgnz9BCDTFCPghDCIND6llnB
	BdZ1ylbvLMwL771z6JRTJL1Aja3+t2j8/utSHIyobKKBJ0Tw035yUI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=Pg0IKD6076fzwB5qRacyw57vY94=; b=vK5bYj0o3c4PMf4dLTjak6RVcYzZ
	zJ2ZaTpstDIoU+U98CdDmddnIssYlU7YwEdfz6TzgU+ofl4/Q8oXBTTbBSKeHN5J
	6nSST04s2PorgIlY+4TUA9c0Rg7ZxxIXi9eOYb0ASdZ8kw5sdtsgtJttfe6oGGtB
	OtqyQg5P5Z+rYBA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Mon, 10 Nov 2014 21:45:00 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
Message-ID:	<20141110204500.GB13071@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<545BBF4B DOT 4020400 AT t-online DOT de> <20141106185019 DOT GK28195 AT calimero DOT vinschen DOT de> <545BD14A DOT 8080803 AT t-online DOT de> <20141106200635 DOT GP28195 AT calimero DOT vinschen DOT de> <20141106204222 DOT GQ28195 AT calimero DOT vinschen DOT de> <545C68BA DOT 3050007 AT t-online DOT de> <20141107101659 DOT GU28195 AT calimero DOT vinschen DOT de> <545D30DA DOT 9040507 AT t-online DOT de> <20141110105151 DOT GB2782 AT calimero DOT vinschen DOT de> <54611048 DOT 4000404 AT t-online DOT de>
MIME-Version:	1.0
In-Reply-To:	<54611048.4000404@t-online.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 mach=
ine 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 "mkpa=
sswd
> >>-l" was mandatory.
> >>
> >>Most *-config scripts using "mkpasswd -l -u USER" may need to be change=
d.
> >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.
>=20
> OK.
>=20
> 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.

> >>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.
>=20
> 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?  Alternatively, is setting some environment
variable feasible for tweaking the output of mkpasswd backward
compatible?


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--SkvwRMAIpAhPCcCJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUYSPMAAoJEPU2Bp2uRE+gr8cP/1Bcc+wzlpViOsGUv0s4x6Y1
MlOuDczwnsuFNP+YYQApp824HunchvvyFIewd2AWFQL6Zf8vgKr1z4kZuVcc3UR1
0e4Jnd7Xo+BVrn3NyJDFGlELhyXNQqwQ3i/bVZzS0MoZcLNfVR5zBC2HUF3106rd
MYTExa8Vlqmn8RRI16Z6tloh0IUXL3KNlaezAWUXsGIt4CJ9DhL3rBICYpRpgZ2C
Y42RgZCnI/2gSqBXfTJa32UIC2RJgN/ZobzXmSD397Kufvcd8oKTM1+4MbvjORxT
KOR04oxd0ps32xhThA23JmKw4ZcyCuJFbtSMm0XLlmGFO/3wMN+441ZfkgRDcLAU
stXD/cwxe9B33IhOvg/J2vmZhs3WQ2JMcgXATcBV10WHKc/cFvhb0lYEZ5HoPcu5
9xmVDBdWtdj4osSdYlnBiXYW86idP7Nc638SSEPUUPpzPmHblJlDmkqMe2kKueVv
JiitUA+YUNwNXTJMTuZ3961C1GfRdYVXlwBKG7MTe7LpOSwpBVZ7cRyOQWNVreVs
zsaBVB96X6Ne8zZWiZxPakoFfDWeWxoRzpVdbYMhxvZ4hEoBVUEUflbydJufu1Zb
cLGW91OtZ4cyzbyLStHHm3YL3COnfL2rUNIl1GigiXNn1yNUFF8xJHGrV1INkcOR
mEEOATfdQh5TSwJ0XIFz
=yb/G
-----END PGP SIGNATURE-----

--SkvwRMAIpAhPCcCJ--

- Raw text -