This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vista + cygwin basics


Corinna Vinschen wrote:
Sorry Brian, but this has only marginally to do with integrity levels.
The real reason for this is the SeCreateGlobalPrivilege introduced with
Windows 2003.  Only administrative users hold this privilege by default,
as well as any process running in terminal server session 0.  Not having
this privile means, you are not allowed to create named shared memory in
the global namespace.  That means, the global shared memory used by
Cygwin can not be created by a non-admin user running in another session
than 0.

This explains another detail I noticed. I have sshd running as a service, under the cyg_server user. As Corinna explains, because it is a service it is running in session 0. If I ssh *in* to the machine and log in as my unprivileged self ME, and type ps...


$ ps -eaf
     UID     PID    PPID TTY     STIME COMMAND
  SYSTEM    5392       1   ?    Apr 18 /usr/bin/cygrunsrv
  SYSTEM    6108    5392   ?    Apr 18 /usr/sbin/cygserver
  SYSTEM    2460       1   ?    Apr 18 /usr/bin/cygrunsrv
  SYSTEM    4780    2460   ?    Apr 18 /usr/sbin/syslog-ng
cyg_serv    2948       1   ?    Apr 18 /usr/bin/cygrunsrv
cyg_serv    3772    2948   ?    Apr 18 /usr/sbin/inetd
cyg_serv    4500       1   ?    Apr 18 /usr/bin/cygrunsrv
cyg_serv    5036    4500   ?    Apr 18 /usr/sbin/sshd
      ME    3804       1   ?    Apr 19 /usr/bin/ssh-agent
      ME    2420       1   ?    Apr 19 /usr/bin/ssh-agent
      ME    6856       1   ?    Apr 20 /usr/bin/ssh-agent
cyg_serv    2260    5036   ?  23:01:57 /usr/sbin/sshd
      ME    1304    2260   0  23:01:59 /usr/bin/bash
      ME    6664       1   ?  23:02:04 /usr/bin/ssh-agent
      ME    7932    1304   0  23:02:07 /usr/bin/ps

even my unprivileged self can see the services -- because as a remotely logged-in user, I inherit the session of the service: 0.

As confirmed by Process Explorer.

However, the bash shell for the remote login is running at the Untrusted IL in session 0, unlike the bash shell for the current at-the-keyboard login, which is running at the Medium IL in session 1.

I'm not sure that's what I'd want...I think I'd want my remote user to be Medium, to, otherwise all kinds of odd sandboxing/virtualization things happen, right?

Up to and including Windows 2003, all console users and all services are
running in TS session 0. Beginning with Vista, even the console logon
is running in a session != 0 and only the services are running in
session 0.

Right. That's what I see -- except for the remote users authenticated by those services in session 0. They don't get a session of their own, but remain in session 0.


Hmmm. I wonder if they SHOULD get a session of their own (which might alleviate any concerns with IL medium processes controlled by a remote user running in session 0 with the services). How would sshd/rlogind/telnetd do that?



Oh, and I now have an explanation for why there are so many ssh-agents running. When I log in remotely, I'm in session 0. I read the .keychain file and get the PID of the current ssh-agent, which is running in session for the at-the-keyboard logon. However, I can't contact it -- it's in a different session. So, keychain starts a new ssh-agent -- AND overwrites the ~/.keychain/${host}-sh file!

Now, while the remote user is still logged in, suppose the desktop starts a new bash --login shell. Well, my ~/.bash_login runs keychain, and sees the PID for the *remote* user's ssh-agent in session 0. Since he's in session 1, he can't contact it, and starts a new ssh-agent -- AND overwrites the ~/.keychain/${host}-sh file AGAIN.

And now I have three different ssh-agents: one for the remote user, and two for the various shells used by the at-the-keyboard user.

Rinse and repeat.

I think I need to teach keychain to use separate files in ~/.keychain/ for different sessions on the same host. Is there a command line tool that I can use to get the session number #if Vista?



With UAC enabled, an administrative user running a normal
shell is running it "non-elevated".  For an admin user that means, she
doesn't hold the SeCreateGlobalPrivilege privilege and the user token
contains the administrators group as "deny only".  An elevated shell
("run as administrator") contains the SeCreateGlobalPrivilege privilege.

But I was logged in as a unprivileged user (non Administrator), so when I selected "run-as-administrator" to launch a bash shell, I had to type in the Administrator's password, and therefore the new shell was elevated.


However, that problem will be fixed in 1.7.0 by using something along
the lines of the Vista/Longhorn "Private Namespaces".  So, with 1.7.0
you will see all Cygwin processes again.  Unless, of course, Microsoft
decides to break my new solution with the next Windows version...

You naughty malware author...


--
Chuck



--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]