This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: admin privileges when logging in by ssh?
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
(per http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview).
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:
> PRIVILEGES INFORMATION
> ----------------------
>
> 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
SE_PRIVILEGE_ENABLED | SE_PRIVILEGE_ENABLED_BY_DEFAULT
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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