Mail Archives: cygwin/2006/02/02/06:57:58
On Feb 1 15:54, Tom Rodman wrote:
> The problem shows up only if your account is *not* added to this
> local group. This local group should have just 1 entry - the
> local administrators group, as in:
>
> $ net localgroup toss_at_will
> Alias name toss_at_will
> Comment test group
>
> Members
>
> -------------------------------------------------------------------------------
> Administrators
> The command completed successfully.
>
> Then try sshing in as a user in the 'Administrators' group, using
> password authentication. My hope is that you will see the problem.
Finally I could reproduce it. Apparently I never read your postings
close enough to do the right thing. D'oh! Sorry about that.
Following happens:
Ssh calls initgroups(3). Cygwin's initgroups(3) creates a group list for
later usage in new user tokens by scanning /etc/passwd and /etc/groups,
as well as adding the global and local Win32 groups the user is
"officially" member of. When looking for local groups, it adds all
local groups for which either the user itself, or another group for
which the user is member of, is member of. I hope that's roughly clear.
The problem is that so-called "Alias SIDs" can also be members of local
groups, even though that's not officially documented in MSDN. The GUI
refuses to add Alias SIDs to local groups, while the CLI (net
localgroup) allows it. Alias SIDs are, for instance "Administrators",
or "Users". That's somewhat weird and hard to explain. I'm not sure I
ever understood the idea behind this scheme.
OK, so far, Cygwin just scanned all members of a local group and added
the group to the user's grouplist, if one of the group members was
itself a group which already showed up in the user's group list. The
problem here is that official logon tokens created by LogonUser don't do
this indirection in case of Alias SIDs. This additional check is
missing in Cygwin so far, so that the group list contains more
supposedly "official" group members than a group list in a really
official token created by LogonUser.
So, later, when setuid(2) is called, Cygwin checks the validity of the
token created by the password login. It finds that this password token
is missing a group which formerly has been added to the user's group
list in the initgroups(3) call. Consequentially the password token is
treated as invalid, and a new token containing the supposedly correct
number of groups is created. This token is then used for the user
context switch and the password logon is accidentally converted into a
password-less logon, with all the consequences of a password-less logon.
I have checked in a patch to Cygwin which adds the missing test. Local
groups are now added to the user's group list only, if either the user
is direct member of the group, or if the user is member of a domain
group or well-known SID which is member of the group.
Er... well... all clearness dispelled? Windows NT security is somewhat
hard to digest, isn't it?
Please give the next snapshot from http://cygwin.com/snapshots/ a try.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -