Mail Archives: cygwin/2006/02/01/09:27:16
On Feb 1 08:07, Tom Rodman wrote:
> On Wed 2/1/06 10:20 +0100 cygwin AT cygwin DOT com wrote:
> > On Jan 31 10:32, Tom Rodman wrote:
> > > Also notable, was that whoami shown: "OurSrvr064\sshd_server", instead of
> > > "staffuser2".
> >
> > That's normal for passwordless login.
>
> Sorry, I should have emphasized that when I ssh'd in, the password was
> *manually* entered. Pls see this test case, which also refers to a
> manually entered ssh password:
>
> http://cygwin.com/ml/cygwin/2006-02/msg00002.html
>
> >From what Pierre Humblet posted in July:
>
> http://cygwin.com/ml/cygwin/2005-07/msg01344.html
>
> if the output of 'id -G' at the console differs from what you get in a
> password authenticated ssh session, then that ssh session will not be
> granted the appropriate rights. In our case we see 1 *additional*
> local group when in the ssh session. What's special about that local
> group is that it contains exactly 1 entry- "administrators". Also, pls
> note that the user that is "sshing in" is in the "administrators" group,
> so even though he is not a direct member of this group, 'id -G' reports
> him as a member in an ssh session, but *not* at a non-ssh (console or
> RDP, bash session)- hence the mismatch that Pierre warns about.
>
> agin, pls see:
>
> http://cygwin.com/ml/cygwin/2006-02/msg00002.html
UI tried your testcase but I can't reproduce this. I created a local
group, added my admin account to it and tried to ssh w/ password into
the machine, in three different ways
- Group is missing in /etc/group
- Group is in /etc/group, user is not present in gr_mem field.
- Group is in /etc/group, user is present in gr_mem field.
In all three cases a native whoami returned my correct user name.
However, I guess you should rework and rematch your group settings in
/etc/group with the group settings in your Windows user database. I
can't tell what exactly is wrong, this is something you'll have to figure
out by some experiments. I assume your group settings are so that on
setuid(), Cygwin finds that the group list does not match the group list
returned in the user token it got from the LogonUser call (which is the
Win32 equivalent for a password logon). The additional requested groups
can only be added by creating a new token. This new token is created
w/o password, since the LogonUser call will never return the correct
group list.
HTH,
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 -