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@docbill.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 > -- > 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/ -- Karsten M. Self http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Spread the real scoop on Xenu and The Church of Scientology, link Scientology on your website.