Message-ID: <480D5D33.9000605@cwilson.fastmail.fm>
Date: Mon, 21 Apr 2008 23:36:19 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Vista + cygwin basics
References: <4802CD4D DOT 2030805 AT cwilson DOT fastmail DOT fm> <480A3B4C DOT 2040205 AT cwilson DOT fastmail DOT fm> <480A4B67 DOT 7911174B AT dessent DOT net> <480BA842 DOT 6010609 AT cwilson DOT fastmail DOT fm> <480C43FC DOT 2FAA58C3 AT dessent DOT net> <20080421085001 DOT GR23852 AT calimero DOT vinschen DOT de>
In-Reply-To: <20080421085001.GR23852@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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/