Mail Archives: cygwin/2006/08/18/09:36:21
On Fri 8/18/06 8:58 +0200 cygwin AT cygwin DOT com wrote:
> On Aug 17 18:49, Tom Rodman wrote:
> >
> > tried that.. no joy, take a look:
> > --v-v------------------C-U-T---H-E-R-E-------------------------v-v--
> > $ $WINDIR/system32/whoami /all #we're in an ssh session before edits made to /etc/group
> >
> > USER INFORMATION
> > ----------------
> >
> > User Name SID
> > ========== =============================================
> > DOMxx1\adm_usr1 S-1-5-21-1390067357-1202660629-682003330-5774
>
> Must be a password logon session, otherwise you would not see this
> user name here, but sshd_server.
Your right, it is a *password authenticated* logon session, such sessions are
fine w/me for system administration work. On a separate issue, rightly
or wrongly we use an expect script w/cron to schedule cron jobs that
access and change files on network shares.
> > $ echo local:S-1-2-0:2:adm_usr1 >> /etc/group
> > $ wc -l /etc/group
> > 2691 /etc/group
> > $ exit
> > logout
> > Connection to OurSrvr065 closed.
> > [16:02:33 Thu Aug 17 0j 36 2354 ~/Mail]
> > [localhost rodmant]$ ssh OurSrvr065 -l adm_usr1 #~adm_usr1 is on a remote share
>
> Won't work, at least not with pubkey authentication.
again - A home dir on a network share, works fine for us w/password
authentication, so the original post/problem is for the password
authentication case - sorry I did not make that clear :-<
It would be interesting to see if you or otheres can duplicate the problem,
using password authentication.
> > adm_usr1 AT OurSrvr065's password:
> > Last login: Thu Aug 17 15:58:07 2006 from 10.165.10.182
> > Welcome to ITZG compile engine ..
> > Could not chdir to home directory /user/adm_usr1: Permission denied
> > -bash: /etc/profile: Permission denied
> > -bash: /user/adm_usr1/.bash_profile: Permission denied
>
> Looks quite expected.
>
> > -bash-3.00$ $WINDIR/system32/whoami /all #notice whoami shows wrong user name:
> >
> > USER INFORMATION
> > ----------------
> >
> > User Name SID
> > ===================== =============================================
> > OurSrvr065\sshd_server S-1-5-21-1390067357-1202660629-682003330-5774
>
> As expected.
>
> > GROUP INFORMATION
> > -----------------
> >
> > Group Name Type SID Attributes
> > ================================ ================ ============================================= ==================================================
> > Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
> > NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
> > LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
>
> Well, here's the LOCAL group. What's the problem? The fact that
> Windows applications asking for the user name get the wrong user name is
> a result of using the logon session of the sshd server process when
> using pubkey authentication.
Yes I see the local group "S-1-2-0", but when I ssh'd in, I typed the
password in for this session and so I expect "whoami /all" to return
the username that goes with the password - more importantly I need the
credentials to write to the network shares, that I normally get when
using ssh via password authentication.
I appreciate your help on this Corinna, *thank-you*. Most work I do does
not seem to require membership in "S-1-2-0", so it's not that big a deal.
> This is a long standing problem, for
> years. There's no workaround for the time being. However, if you take
> a look into the user token of the process using other means
> (OpenProcessToken/GetTokenInformation), you'll see that the token user,
> as well as the token owner is set to the user account you logged in to,
> DOMxx1\adm_usr1 in this case.
Thanks, I trust your right, I don't have the experience or time to
write a simple tool using (OpenProcessToken/GetTokenInformation); maybe
I can google and find such a tool..
--
Thank-you,
Tom
> Why the Windows functions returning the user name from a SID fail to
> return the correct user name (as for whoami) in this scenario, is
> beyond me. This is arguably a Windows bug.
>
>
> 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 -