Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date: Mon, 30 Jun 2003 08:45:48 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Brian DOT Kelly AT empireblue DOT com
cc: cygwin AT cygwin DOT com
Subject: Re: About the 'su' command
In-Reply-To: <OF019A08D6.933BBC82-ON85256D55.004359DD@empirehealthcare.com>
Message-ID: <Pine.GSO.4.44.0306300843160.29425-100000@slinky.cs.nyu.edu>
Importance: Normal
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Brian,

That's the reason behind the cygdaemon effort.  So "somebody" is doing
it...
	Igor

On Mon, 30 Jun 2003 Brian DOT Kelly AT empireblue DOT com wrote:

> >> Why rewrite 'su' to do those types of tricks, when 'ssh' already exists?
>
> Uhhh - how about "script portability??"
>
> (Which is why I predict su will "someday" be made to do this. When??
> Simple,
> When somebody does it .... ) [ I ain't demand'in nothin from nobody ]
>
> Brian Kelly
>
>
> "Karsten M. Self" <kmself AT ix DOT netcom DOT com>@cygwin.com on 06/29/2003 07:34:57 PM
> Sent by:    cygwin-owner AT cygwin DOT com
> To:    cygwin AT cygwin DOT com
> cc:     (bcc: Brian Kelly/WTC1/Empire)
> Subject:    Re: About the 'su' command
>
> 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/