Mail Archives: cygwin/2003/06/30/08:41:35
It is. See <http://cygwin.com/cygwin-ug-net/ntsec.html#NTSEC-SETUID>.
Igor
On Mon, 30 Jun 2003, Karsten M. Self wrote:
> Is this, or could this be made, part of the standard Cygwin docs and/or
> FAQ?
>
> Very nice explanation, Bill.
>
> Peace.
>
> on Wed, Jun 18, 2003 at 08:51:24AM -0400, Bill C. Riemers (cygwin AT docbill DOT net) wrote:
> >
> > > The second says the command wont work unless I have appropriate
> > > privileges.
> > > Do you know "someone" on an XP station that has more powers than the
> > > Administrator or an Administrators member ?
> >
> > On most Unix systems, if you create a user with UID 65535 you will find that
> > user is unable to run 'suid' commands including 'su'. This is result of
> > 65535 mapping to -1 as a short, and -1 having special meaning. For awhile
> > there was a trend to make the "nobody" user 65535. But then with the dawn
> > of the web, programmers started wanting to make SUID cgi-bin scripts, while
> > still using "nobody" as the default user for web connections. As such, the
> > practice using 65535 for "nobody" has for the most part been abandoned in
> > the Unix world.
> >
> > However, someone at Microsoft must have thought this was an extremely good
> > idea. And why just have one account which is not allowed to SUID? So
> > instead, Microsoft wrote XP so any account != UID 18 is prohibited from
> > SUID. (OK. I over simplified, you can actually grant other accounts
> > privilege to SUID on XP professional...)
> >
> > At first thought, the idea of restricting SUID to SYSTEM seems to give XP
> > much stronger security than most unix systems. Until, you stop and
> > consider, if only SYSTEM can SUID, and I can't login as SYSTEM, how does
> > anything ever get installed to run under SYSTEM? It turns out SYSTEM is the
> > account used for running services. Anyone with Administrators privilege can
> > add a new service. Consequently, all Administrators can run any program
> > they like as SYSTEM, including of course 'su'.
> >
> > So, you ask, if it is so easy for Administrator to run a process as SYSTEM,
> > why doesn't 'su' use this trick? Quite simple. You can not change an
> > existing process to SYSTEM privileges, nor can you do a direct exec() so you
> > can pass your open file descriptors and environment to the new process.
> > Consequently, you would find that if su used this "trick" your process would
> > be running under a new TTY without access to existing file descriptors. So
> > a command like, 'su root -c "bar.sh" < /tmp/foo' would not work as expected.
> >
> > Now you ask, "Well then, why can ssh do pipes." Very simple, 'ssh' sticks
> > around after starting the child process starts passing data from open file
> > descriptors though sockets.
> >
> > Finally you ask, "If ssh can do that, why doesn't su?" Simple. Why rewrite
> > 'su' to do those types of tricks, when 'ssh' already exists?
> > Bill
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
--
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 -