admin privileges when logging in by ssh?

Corinna Vinschen
Fri Oct 14 18:24:00 GMT 2011

On Oct 14 11:18, Andrew Schulman wrote:
> When user backup logs in by ssh, he gets different results:
>   * If he logs in by password authentication, then whoami /all shows 
> the right user name and privileges, and he can use the privileges.  See 
> Listing 1 below.  So this is fine.
>   * If he logs in by pubkey authentication, he doesn't get the backup and
> restore privileges.  See Listing 2 below.  This is confirmed by e.g.
> backup@sulfur ~
> $ cat /etc/ssh_host_dsa_key
> cat: /etc/ssh_host_dsa_key: Permission denied

Hang on, this is strange...

> So the difference AFAICT is the membership in the Administrators group.
> Notice also in the two listings below, that by password authentication,
> backup gets
> Mandatory Label\High Mandatory Level
> while by pubkey, he gets
> Mandatory Label\Medium Mandatory Level
> whatever those are.

That's an UAC thingy.  Keep in mind that Cygwin has to create the user
token from scratch here, given that you are using passwored-less setuid
method 1
I'm not aware of a method to fetch the mandatory level SID a user is
supposed to get, so what Cygwin does is simply to base the mandatory
level SID on the membership in the admins group.

As for the missing privileges, they are not missing in the user token,
they are just disabled:

> ----------------------
> Privilege Name                Description                               State   
> ============================= ========================================= ========
> SeBackupPrivilege             Back up files and directories             Disabled
> SeRestorePrivilege            Restore files and directories             Disabled
> SeShutdownPrivilege           Shut down the system                      Enabled 
> SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled 
> SeUndockPrivilege             Remove computer from docking station      Enabled 
> SeImpersonatePrivilege        Impersonate a client after authentication Disabled
> SeCreateGlobalPrivilege       Create global objects                     Enabled 
> SeIncreaseWorkingSetPrivilege Increase a process working set            Enabled 
> SeTimeZonePrivilege           Change the time zone                      Enabled 

So the privileges are correctly collected by Cygwin and correctly put
into the user token.

The strange fact here is that they are disabled.  When Cygwin creates
the privilege list for the new token, it sets the privileges to


So, for a Cygwin-created token, I'd expect that all privileges in the
token's privilege list are enabled.

But even then, a disabled privilege in a user token is usually not a big
problem.  It's kind of a safety feature in Windows that "dangerous"
privileges are not enabled by default.  Rather it is expected behaviour
that an application which wants to make use of a privilege enables the
privilege using the AdjustTokenPrivileges function, makes use of the
privilege, and then disables the privilege again.  That is supposed to
avoid dangerous actions to work accidentally, just because the user can
do so.

But even then, if the backup/restore privileges are disabled, it shouldn't
matter in Cygwin.  Cygwin enables both privileges right at process startup.

Having said that, I have no idea why the privileges are disabled in your
token.  The good news is that I can reproduce the behaviour on a Windows
2008 R2 box with a normal domain user account, which got explicit backup
and restore rights.

I don't know why this occurs when using password-less setui method 1,
this is something which I have to debug yet.  However, here's the other
good news:  When using password-less setui method 3, it works fine.


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

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list