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=f8MwdsZJfdyS0NB6OVvoUsa4TI92JfVeo7ceb0rtE03dUxbfZCmOR
	My38b5j5B80nkBMGACNlYajEhwUOzUWV1Et4QYoARkYtjfKsDLVxvMG338f4NoF4
	Rp4LXcVwS6NSN2fTOKCOGtE+6xC2F7EcYkijV8HrPJS/vnELCVYgX4=
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=w/tmydMuB5S+U8dXgkLUKC1q1Xo=; b=WVPtwlml83+GDarNLwOj9lOaFJqh
	9G4Ed0yxI2smsYcHzVS7OD6c+debTSicdcoLgVI/74nL53ChQTUvCufRtA8mdYLG
	Z+pizHyMvc6HtE8mxiL7pfYqPnzR00/zm48PYYoAzCIlScRBSdsGb2JZKuURP0FZ
	O7G1vZNqqyz9VkI=
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=-0.5 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Fri, 18 Oct 2013 20:24:18 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: lnn, a native symlink wrapper script (Was: fstab not automounting...)
Message-ID:	<20131018182418.GN23477@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<21087 DOT 31348 DOT 870054 DOT 516829 AT consult DOT pretender> <20131017093846 DOT GA26304 AT calimero DOT vinschen DOT de> <21087 DOT 64099 DOT 660195 DOT 262020 AT consult DOT pretender> <20131017151929 DOT GR18358 AT calimero DOT vinschen DOT de> <21088 DOT 45642 DOT 198102 DOT 464479 AT consult DOT pretender> <20131018074744 DOT GD23477 AT calimero DOT vinschen DOT de> <5261762F DOT 30707 AT etr-usa DOT com>
MIME-Version:	1.0
In-Reply-To:	<5261762F.30707@etr-usa.com>
User-Agent:	Mutt/1.5.21 (2010-09-15)

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

On Oct 18 11:55, Warren wrote:
> On 10/18/2013 01:47, Corinna Vinschen wrote:
> >   $ CYGWIN=3Dwinsymlinks:native ln -s /path/to/your/fstab /etc/fstab
>=20
> I've wrapped that in a shell script called lnn ("link native"):
>=20
>     #!/bin/sh
>     CYGWIN=3Dwinsymlinks:native ln "$@"
>=20
> Perhaps Eric Blake will add this to coreutils so we can use the
> shortcut in replies to list questions.
>=20
> I tried to add a test for the SeCreateSymbolicLinkPrivilege
> capability before attempting to create the link, but this command
> doesn't DTRT:
>=20
> 	`cygpath -S`/whoami /priv
>=20
> It doesn't output a line for SeCreateSymbolicLinkPrivilege at all.
>=20
> The native whoami.exe has an /all flag that *does* show this
> privilege, but you only get a line for the symlink priv when you run
> it as Administrator!

Which is perfectly correct.  You seem to have a misunderstanding what
whoami does.  It prints the privileges which are present in the current
user token.  And, assuming you didn't change the default settings,
SeCreateSymbolicLinkPrivilege is not present in the user token of a
normal user, nor in the UAC-crippled user token of an admin user.

And since you're asking.  The "State" printed by whoami, "Enabled" or
"Disabled", does not mean a process running with this user token holds a
privilege or not.  Rather it means, the process holds the privilege.
It's just either enabled or disabled.

The idea here is to secure a user token against unintentional usage of a
dangerous privilege.  It has to be enabled before the process can call
the dangerous functionality, using AdjustTokenPrivileges, for instance.
Yes, exactly, the process itself may change a privilege in its user
token from disabled to enabled, and it even has to do that to call
certain OS functions.

So we have three states:

- The user token does not contain a privilege.

  The process can not perform the dangerous action secured by that
  privilege.  At all.

- The user token contains a privilege, but it's disabled.

  The process can not perform the dangerous action secured by that
  privilege.  But it can enable the privilege if it wants to perform
  that action.

- The user token contains a privilege, and it's enabled.

  The process can perform the dangerous action secured by that privilege.

Does it make more sense now?


Corinna

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSYXzSAAoJEPU2Bp2uRE+gGYUP/113lqS3vSrssOLNufG8hd+M
9CZjOohXKwQ3i9F/3sNXtoVNpmCiybUV9p4T7XEv2gfOrPItuUVCb8rCg/dzMf1t
2E52hy9plju/TUHuEBsTNKjII/UZ/gFempExrmveEEL6M60qZTx5wL0e59LMoP5Q
aGPIoGPWnu/1h3aTvoly2mr5jwa28pHtjR/j7+UkBX6A6byeXPTlC76iRuEebEus
792bHgm/WX1fNn4pWDvdKfhGUrP151qni8zNORiDvvlYqXrnq/vfDjSDvY35j7qu
FcJNaCmwuClh3wESF1H5kS7v1xgvkc6JwTd5aTdxSrYvfee500t9QBvvO3WVOJ0b
PlCQS1XX10SxZa/Vd8h43I8UYCPEsuqi6s5Dj9oC0WvYswuR411gDu6loQBvAavn
fRUj5hz9boDXHpgJWUD1f7YAGuDLqt28jvCIztfWeen31YanNBuGa+PIloS5uNYz
69QQGy6zXDhdPVL68G9trcwtpqKKn/pKIVu4k/E8gZ5cpCOGN4HWUoftl5cNhrF4
1C0EIMKETacYKoNCbfFNUmZrNpd4NuEyYggwo9XF/YDxkUhkgIX9ARGX3GPtBAkU
/5aAF4cZHqIWVuMm6fdBiesAYfuTse/re1ii8eC5ljnRUKK3Ps2nBDbNRoqwtj5m
tFxNcyEdXwW98IG4lHmz
=m7e9
-----END PGP SIGNATURE-----

--Z1OTrj3C7qypP14j--

- Raw text -