Vista + cygwin basics
Corinna Vinschen
corinna-cygwin@cygwin.com
Mon Apr 21 08:53:00 GMT 2008
On Apr 21 00:36, Brian Dessent wrote:
> You can clear this all up with process explorer:
>
> Unelevated bash shell:
> - user 'brian'
> - IL medium
> - session 1
> - shared memory area \Sessions\1\BaseNamedObjects\cygwin1S4.shared.4
>
> Elevated bash shell
> - user 'brian'
> - IL high
> - session 1
> - shared memory area \BaseNamedObjects\cygwin1S4.shared.4
>
> syslog-ng service
> - user 'NT AUTHORITY\SYSTEM'
> - IL System
> - session 0
> - shared memory area \BaseNamedObjects\cygwin1S4.shared.4
>
> So as you can see, Cygwin tries to create its shared section in the
> global namespace, but doing this requires administrator privileges, so
> it can only do it if elevated (or UAC disabled.) This explains I think
> everything that you saw.
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. You can find more details about this privilege which, IMHO, is
obscurity rather than security, for instance here:
http://msdn2.microsoft.com/en-us/library/aa366537.aspx
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. 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.
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...
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/
More information about the Cygwin
mailing list