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: lnn, a native symlink wrapper script (Was: fstab not automounting...)


On Oct 18 11:55, Warren wrote:
> On 10/18/2013 01:47, Corinna Vinschen wrote:
> >   $ CYGWIN=winsymlinks:native ln -s /path/to/your/fstab /etc/fstab
> 
> I've wrapped that in a shell script called lnn ("link native"):
> 
>     #!/bin/sh
>     CYGWIN=winsymlinks:native ln "$@"
> 
> Perhaps Eric Blake will add this to coreutils so we can use the
> shortcut in replies to list questions.
> 
> I tried to add a test for the SeCreateSymbolicLinkPrivilege
> capability before attempting to create the link, but this command
> doesn't DTRT:
> 
> 	`cygpath -S`/whoami /priv
> 
> It doesn't output a line for SeCreateSymbolicLinkPrivilege at all.
> 
> 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

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

Attachment: pgpV3YulzXrL1.pgp
Description: PGP signature


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