Request for help debugging screen problem

Shaddy Baddah
Sun Feb 7 14:01:00 GMT 2010

Hi Corinna,

On 6/02/2010 10:59 AM, Corinna Vinschen wrote:
> On Feb  5 16:48, Shaddy Baddah wrote:
>> On 5/02/2010 4:38 PM, Corinna Vinschen wrote:
>>> On Feb  5 16:23, Shaddy Baddah wrote:
>>>> To open a handle to another local process and obtain full access
>>>> rights, you must enable the SeDebugPrivilege privilege. For more
>>>> information, see Changing Privileges in a Token.
>>> I'm not sure.
>>>> Would this be in the user token? How can I list which privileges are
>>>> contained in the token for the mintty session and the ssh session?
>> Thanks for that. I compiled it (using gcc-3. Doesn't compile with
>> gcc-4) and ran it. If anything, the ssh session has one more item in
>> DefaultDacl and SecurityDescriptor. But I haven't grasped the
>> concepts yet. And it's getting v. late here in +1100 zone, so I'll
>> have to have a look at the next opportunity.
> The DefaultDacl and SecurityDescriptor shouldn't make a difference.
> Btw., if you give an arbitrary argumented to gettokinfo, as in
>    $ gettokinfo 1
> you also get the full list of user privileges.
> However, tonight (no, this is *not* funny anymore) it occured to me what
> the problem is.
> It's not the debug privilege.
> It's Session Isolation.
> Up to Windows 2003, the desktop and the services are running in the same
> session 0.  Starting with Windows Vista, only the service processes are
> still running in session 0, while all other sessions including the local
> desktop are running in other sessions.  Non-admin users and restricted
> (not-elevated) admin users have no right to penetrate the session
> barrier.  That's the reason the OpenProcess fails with
> However, this shouldn't be the case for cygrunsrv if it's running in
> session 0 under the SYSTEM account.  The system user should have
> permission to break the session barrier.  What problem occurs in
> cygrunsrv exactly when it's running?
> I'd still prefer to get this all working without cygrunsrv, but the
> current method using OpenProcess is impossible in that scenario.  We
> have to find some other method.  In the menatime it would help to learn
> why the method using cygrunsrv fails.

I'm sorry, I have abandoned inspect what the issue with cygserver is 
because I've realised what the real situation is. int 
fhandler_tty_slave::open (int, mode_t) needs to call OpenProcess with 
PROCESS_DUP_HANDLE on the tty master process. When logged in via ssh, 
this is the dedicated sshd process still owned by cyg_server.

Using ProcExplorer, I see that the regular Users grouped user (shaddy 
account actually) does not have any permissions to this process. The 
(full) permissions are only for:


Is this due to a recent security change (I vaguely recall some mailing 
list discussion around something close to this)? Is this the reason for 
the cygserver alternative?

I suspect it is. The cygserver failure is as I described in the initial 
post (I'll unabandon cygserver and reconfirm the problem with using it). 
ReadFile() was failing with ERROR_ACCESS_DENIED. I'll focus on it for 
the moment and let others mull over if the sans-cygserver mode should be 
working, or catered for.


More information about the Cygwin-developers mailing list