Re: About the 'su' command

Re: About the 'su' command

[Brian.Kelly]

[-- Attachment #1: Type: text/plain, Size: 4470 bytes --]


>> 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@ix.netcom.com>@cygwin.com on 06/29/2003 07:34:57
PM

Sent by:    cygwin-owner@cygwin.com


To:    cygwin@cygwin.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@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 <kmself@ix.netcom.com>
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
       <a href="http://xenu.org/";>Scientology</a> on your website.



"WellChoice, Inc." made the following
 annotations on 06/30/2003 08:24:55 AM
------------------------------------------------------------------------------
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement

[-- Attachment #2: C.DTF --]
[-- Type: application/octet-stream, Size: 198 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+/3ehefG8443k044RAoe6AJ0TjVkcGer+yoA5gj7tb3tIkEr6EACcDlKw
1yAaBD7xZZ5THmGkppvDJd4=
=Lrn1
-----END PGP SIGNATURE-----


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

Re: About the 'su' command

[Igor Pechtchanski]

Brian,

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

On Mon, 30 Jun 2003 Brian.Kelly@empireblue.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@ix.netcom.com>@cygwin.com on 06/29/2003 07:34:57 PM
> Sent by:    cygwin-owner@cygwin.com
> To:    cygwin@cygwin.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@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

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/

Re: About the 'su' command

[Elfyn McBratney]

On Mon, 30 Jun 2003, Igor Pechtchanski wrote:

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

In-fact, I'm working on this ATM. And, it's coming along nicely, thank you very
much! :-)

Elfyn

> On Mon, 30 Jun 2003 Brian.Kelly@empireblue.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@ix.netcom.com>@cygwin.com on 06/29/2003 07:34:57 PM
> > Sent by:    cygwin-owner@cygwin.com
> > To:    cygwin@cygwin.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.

-- 


--
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/

Re: About the 'su' command

[Brian Dessent]

Brian.Kelly@empireblue.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

Microsoft has a su utility in one of their NT resource kits:


----8<----
Usage: 

su <user> "[cmdline]" [domain] [[winsta\]desktop] [options]

<user>
The first non-switch argument is the username for the new process.
This is the only required argument.

"[cmdline]"
The second non-switch argument is the command line to execute as <user>.
This argument is optional.  If it is not specified, the default command
processor specified in the environment variable %comspec% is executed.

[domain]
The third non-switch argument is the domain name for the target user.
This argument is optional.  If it is not specified, default domain
lookup will occur.  In this case the domain lookup is executed in the
following order, until the domain for the target user is found:
  Well-known, built-in, local accounts, primary domain, trusted domains
Specifying "." as the domain limits the search for the user account to
the local computer.
Not specifying a domain causes account lookup in the following order:
  Well-known, built-in, local accounts, primary domain, trusted domains.

[[winsta\]desktop]
The fourth non-switch argument is the target windowstation and desktop
for the new process.
This argument is optional.
Winsta0\Default is the user default interactive Windowstation and
desktop.
This argument can be specified with only the desktop name.  Not
specifying a windowstation name causes the process to run on the current
windowstation in the supplied desktop.  When specifying a windowstation,
the windowstation and desktop pair must be delimited as follows:     
"windowstationname\desktopname"
Not specifying any desktop for the new process causes the process to run
on the same windowstation and desktop from which SU was launched,
launching a child on the current Winsta\Desktop.


[options]
One or more option switches, also called flags, can be specified in any
order, anywhere on the command line.  All switches are optional.


-cb
Do not create new console.
If the new process is a console process, it inherits the console of the
caller.
This option should not be combined with -w when starting console
applications.  Furthermore, the password should not be supplied when
redirecting passwords when starting console applications.
This switch should not be used with redirected passwords.

-dn
Do not switch to new desktop.
If the new process is set to run on a desktop which differs from the
current desktop, the default behavior is to switch to the new desktop,
making the new desktop active and bringing it to the foreground.  This
option overrides the default and prevents switching to the new desktop.
Note that SU does not return until the new process exits, unless the -w
switch is specified.

-e
Disable environment preparation.
The parent environment is inherited. 
This option prevents preparation of the user environment for the new
process, instead causing the environment to be inherited from SU.

-l
Disable loading of the user Registry hive.
.Default is used instead.
This option prevents loading of the user Registry hive for the target
user.
If the hive happens to be loaded for the target user, the new process
behaves the same way with HKEY_CURRENT_USER that it would if -l were not
specified.  If -l is specified without -e, a user default environment is
created for the new process, as opposed to creating a user-specific
environment for the new process.

-v
Display verbose output to STDOUT (standard output).
This option displays details related to the creation of the new process.

-w
Do not wait on child.
The Registry hive remains loaded.
When this option is specified, SU does not wait for the new process to
exit before returning to the caller.  This means that SU cannot unload
the user Registry hive for the target user if a hive was loaded on
behalf of that user.
This flag should not be combined with the -cb flag when starting a
console-based application; if it is, console output is intermixed.


One of the following logon types may also be specified as an option. 
The default type is interactive.

-b
Batch
The target user must possess the SeBatchLogonRight logon type.
This logon type is not used by Microsoft, but is available for use in
custom applications.

-i
Interactive
The target user must possess the SeInteractiveLogonRight logon type.
This is the same logon type that occurs when a user physically logs onto
a computer running Windows NT Workstation or Windows NT Server.

-s
Service
The target user must possess the SeServiceLogonRight logon type.
The logon type is for service style logons performed by the service
control manager.

-n
Network
The target user must possess the SeNetworkLogonRight logon type.
This logon type is for network-style logons, such as impersonation over
named pipes or connection over shares.  Such a logon can be useful for
testing network user access to resources on the local computer.
This option is supported only on the Windows NT 4.0 platform.

----8<----

If su is needed it seems to me like one should just use MS's tool.  Am I
missing something?

Brian

--
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/

Re: About the 'su' command

[Elfyn McBratney]

On Tue, 1 Jul 2003 Brian.Kelly@empireblue.com wrote:

>
> >> Am I missing something?
>
> In my not-so-humble opinion, "script portibility" means copy script to box,
> "maybe" chmod it to make it executable - and GO!! I'm guessing that "su"
> will be part of the future default capability of cygwin.

So do we, but it takes more than download, chmod and go. You have to take into
consideration those poor user's without a security model.

The Cygwin daemon will hopefully take care of all of this user-context
switching, as long as the OS (NT/20003/XP/2003) supports it and is set-up
correctly.

 The only problem I
> have with the Resource Kit su is that - well - "it's in the Resource Kit".
> Which means I have to hunt it down and install it -
> or even worse "purchase it" UHHGGGG!!! MS has a nasty habit of "dropping
> support" for their junk and "cleaning" thier website of things like "old"
> resource kits - or at the very least, moving it around and making it a
> ROYAL PAIN to find.
> I hate going to MS for anything - it just plain SUCKS. Plus I have no idea
> how well MS su even works with cygwin. Have you used the two together??

I consider this to be blasfamous. ;-)

Elfyn
-- 


--
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/

Re: About the 'su' command

[Brian.Kelly]

>> Am I missing something?

In my not-so-humble opinion, "script portibility" means copy script to box,
"maybe" chmod it to make it executable - and GO!! I'm guessing that "su"
will be part of the future default capability of cygwin. The only problem I
have with the Resource Kit su is that - well - "it's in the Resource Kit".
Which means I have to hunt it down and install it -
or even worse "purchase it" UHHGGGG!!! MS has a nasty habit of "dropping
support" for their junk and "cleaning" thier website of things like "old"
resource kits - or at the very least, moving it around and making it a
ROYAL PAIN to find.
I hate going to MS for anything - it just plain SUCKS. Plus I have no idea
how well MS su even works with cygwin. Have you used the two together??

Brian Kelly






"Brian Dessent" <brian@dessent.net>@cygwin.com on 07/01/2003 08:09:57 AM

Sent by:    cygwin-owner@cygwin.com


To:    cygwin@cygwin.com
cc:     (bcc: Brian Kelly/WTC1/Empire)

Subject:    Re: About the 'su' command


Brian.Kelly@empireblue.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

Microsoft has a su utility in one of their NT resource kits:


----8<----
Usage:

su <user> "[cmdline]" [domain] [[winsta\]desktop] [options]

<user>
The first non-switch argument is the username for the new process.
This is the only required argument.

"[cmdline]"
The second non-switch argument is the command line to execute as <user>.
This argument is optional.  If it is not specified, the default command
processor specified in the environment variable %comspec% is executed.

[domain]
The third non-switch argument is the domain name for the target user.
This argument is optional.  If it is not specified, default domain
lookup will occur.  In this case the domain lookup is executed in the
following order, until the domain for the target user is found:
  Well-known, built-in, local accounts, primary domain, trusted domains
Specifying "." as the domain limits the search for the user account to
the local computer.
Not specifying a domain causes account lookup in the following order:
  Well-known, built-in, local accounts, primary domain, trusted domains.

[[winsta\]desktop]
The fourth non-switch argument is the target windowstation and desktop
for the new process.
This argument is optional.
Winsta0\Default is the user default interactive Windowstation and
desktop.
This argument can be specified with only the desktop name.  Not
specifying a windowstation name causes the process to run on the current
windowstation in the supplied desktop.  When specifying a windowstation,
the windowstation and desktop pair must be delimited as follows:
"windowstationname\desktopname"
Not specifying any desktop for the new process causes the process to run
on the same windowstation and desktop from which SU was launched,
launching a child on the current Winsta\Desktop.


[options]
One or more option switches, also called flags, can be specified in any
order, anywhere on the command line.  All switches are optional.


-cb
Do not create new console.
If the new process is a console process, it inherits the console of the
caller.
This option should not be combined with -w when starting console
applications.  Furthermore, the password should not be supplied when
redirecting passwords when starting console applications.
This switch should not be used with redirected passwords.

-dn
Do not switch to new desktop.
If the new process is set to run on a desktop which differs from the
current desktop, the default behavior is to switch to the new desktop,
making the new desktop active and bringing it to the foreground.  This
option overrides the default and prevents switching to the new desktop.
Note that SU does not return until the new process exits, unless the -w
switch is specified.

-e
Disable environment preparation.
The parent environment is inherited.
This option prevents preparation of the user environment for the new
process, instead causing the environment to be inherited from SU.

-l
Disable loading of the user Registry hive.
.Default is used instead.
This option prevents loading of the user Registry hive for the target
user.
If the hive happens to be loaded for the target user, the new process
behaves the same way with HKEY_CURRENT_USER that it would if -l were not
specified.  If -l is specified without -e, a user default environment is
created for the new process, as opposed to creating a user-specific
environment for the new process.

-v
Display verbose output to STDOUT (standard output).
This option displays details related to the creation of the new process.

-w
Do not wait on child.
The Registry hive remains loaded.
When this option is specified, SU does not wait for the new process to
exit before returning to the caller.  This means that SU cannot unload
the user Registry hive for the target user if a hive was loaded on
behalf of that user.
This flag should not be combined with the -cb flag when starting a
console-based application; if it is, console output is intermixed.


One of the following logon types may also be specified as an option.
The default type is interactive.

-b
Batch
The target user must possess the SeBatchLogonRight logon type.
This logon type is not used by Microsoft, but is available for use in
custom applications.

-i
Interactive
The target user must possess the SeInteractiveLogonRight logon type.
This is the same logon type that occurs when a user physically logs onto
a computer running Windows NT Workstation or Windows NT Server.

-s
Service
The target user must possess the SeServiceLogonRight logon type.
The logon type is for service style logons performed by the service
control manager.

-n
Network
The target user must possess the SeNetworkLogonRight logon type.
This logon type is for network-style logons, such as impersonation over
named pipes or connection over shares.  Such a logon can be useful for
testing network user access to resources on the local computer.
This option is supported only on the Windows NT 4.0 platform.

----8<----

If su is needed it seems to me like one should just use MS's tool.  Am I
missing something?

Brian

--
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/







"WellChoice, Inc." made the following
 annotations on 07/01/2003 08:54:42 AM
------------------------------------------------------------------------------
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement


--
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/

Re: About the 'su' command

[andrew brian clegg]

On Mon, 30 Jun 2003, Karsten M. Self wrote:

> on Wed, Jun 18, 2003 at 08:51:24AM -0400, Bill C. Riemers wrote:

> > 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.

Bit of a tangent, but -- did anyone ever figure out what all those
transient connections between non-priv ports on localhost are for when you
type stuff into an ssh session?

There was a bit of discussion on here a few months ago about it, but I'm 
not sure it ever got resolved, and I've just started to see it myself 
having finally installed ssh...

Andrew.



--
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/

Re: About the 'su' command

[Brian.Kelly]

                _____(____
              /                         \
                     /                              \
                              |          O       O         |
                              |                ^              |
                               \          \____/        /
                                 \___________/





"Igor Pechtchanski" <pechtcha@cs.nyu.edu> on 06/30/2003 08:45:48 AM

Please respond to cygwin@cygwin.com

To:    Brian.Kelly@empireblue.com
cc:    cygwin@cygwin.com

Subject:    Re: About the 'su' command


Brian,

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

On Mon, 30 Jun 2003 Brian.Kelly@empireblue.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@ix.netcom.com>@cygwin.com on 06/29/2003
07:34:57 PM
> Sent by:    cygwin-owner@cygwin.com
> To:    cygwin@cygwin.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@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

--
    http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_            pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_        igor@watson.ibm.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














"WellChoice, Inc." made the following
 annotations on 06/30/2003 09:58:54 AM
------------------------------------------------------------------------------
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement


--
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/

Re: About the 'su' command

[Igor Pechtchanski]

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@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

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/

Re: About the 'su' command

[Karsten M. Self]

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

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 <kmself@ix.netcom.com>        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
       <a href="http://xenu.org/";>Scientology</a> on your website.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: About the 'su' command

[Larry Hall]

Ross Presser wrote:

> Larry Hall <cygwin-lh@cygwin.com> wrote in news:3EEFA434.90409@cygwin.com:
> 
> 
>>>Do you know "someone" on an XP station that has more powers than the
>>>Administrator or an Administrators member ?
>>
>>
>>Certainly.  SYSTEM.  But I'd highly recommend using ssh instead of
>>su.  That way you don't have to create a user with privileges that
>>opens a security hole just so you can su.  Of course, you can do
>>so if you prefer.
> 
> 
> SYSTEM doesn't have the power to use network resources, does it?
> 


As Corinna pointed out very well in this thread, access to network
resources is controlled by Windows authentication.  SYSTEM has the
permissions that allow it to switch user context, and doing so may or may
not include authentication.  But I was answering your question about which
ID has permissions (by default) to change to a new user ID.  Network
resource access is a different, though related, issue.


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746


--
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/

Re: About the 'su' command

[Ross Presser]

Larry Hall <cygwin-lh@cygwin.com> wrote in news:3EEFA434.90409@cygwin.com:

>> Do you know "someone" on an XP station that has more powers than the
>> Administrator or an Administrators member ?
> 
> 
> Certainly.  SYSTEM.  But I'd highly recommend using ssh instead of
> su.  That way you don't have to create a user with privileges that
> opens a security hole just so you can su.  Of course, you can do
> so if you prefer.

SYSTEM doesn't have the power to use network resources, does it?

-- 
Ross Presser -- rpresser AT imtek DOT com
"... VB is essentially the modern equivalent of vulgar Latin in 13th 
Centurary Europe. Understand it, and you can travel to places you never 
heard of and still understand some people." -- Alex K. Angelopoulos


--
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/

Re: About the 'su' command

[Bill C. Riemers]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]


> 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

[-- Attachment #2: su.dat --]
[-- Type: application/octet-stream, Size: 2065 bytes --]

#!/usr/bin/bash
# assign the environment to a
a=`env |sed -n -e '/^!::=/d' -e 's,$,_EOL_,g' -e 's,'\'',_APOS_,g' -e 's/\([A-Za-z0-9_][A-Za-z0-9_]*\)=/'\'';\1='\''/' -e '/./p'`

rm -f /tmp/env.$$
echo "#!`which bash`" > /tmp/env.$$
chmod 755 /tmp/env.$$

userarg="Administrator"

options=":lc:fmps:"
repeat=1;
while [ $repeat -ne 0 ] ; do
  getopts $options arg
  if [ $? -ne 0 ] ; then
    arg="$1"
    OPTIND=2
  fi
  case "x$arg" in 
    xl | x- | x--login)
      loginarg=1
      if [ -z "$shellarg" ] ; then
        shellarg=`which bash`
      fi
      ;;
    xc | x--command | x--command)
      commandarg="$OPTARG"
      ;;
    x--command=*)
      commandarg="${arg##--command=}"
      ;;
    xf | x--fast )
      fastarg=1
      if [ -z "$shellarg" ] ; then
        shellarg=`which tcsh`
      fi
      if [ -z "$shellarg" ] ; then
        shellarg=`which csh`
      fi
      ;;
    xm | xp | x--preserve-environment)
      echo $a|sed -e 's,^'\'';,,' -e 's,_EOL_$,'\'',' -e 's,_EOL_ '\'';,'\'';\
,g' -e "s,_APOS_,'\\'',g" -e 's,_EOL_ ,\
,g' >> /tmp/env.$$
      env|sed -n -e 's,\([A-Za-z0-9_][A-Za-z0-9_]*\)=.*,export \1;,p' >> /tmp/env.$$
      preservearg=1
      ;;
    xs )
      shellarg="$OPTARG"
      ;;
    x--shell)
      shellarg="$OPTARG"
      OPTIND=3
      ;;
    x--shell=*)
      shellarg="${arg##--shell=}"
      ;;
    *)
      repeat=0
      OPTIND=1
      ;;
  esac
  while [ $OPTIND -gt 1 ] ; do
    shift
    OPTIND=`expr $OPTIND - 1`
  done
done
if [ -n "$1" ] ; then
  userarg="$1"
  shift
fi
if [ -z "$shellarg" ] ; then
  shellarg=`which bash`
fi
if [ -n "$commandarg" ] ; then
  echo "exec \"$shellarg\" $fastarg $loginarg -c \"$commandarg\"" >>/tmp/env.$$
elif [ -n "$*" ] ; then
  echo "exec \"$shellarg\" $fastarg $loginarg -c \"$@\"" >>/tmp/env.$$
else
  echo "exec \"$shellarg\" $fastarg $loginarg -i -s" >>/tmp/env.$$
fi
echo "cd '`pwd`'">>/tmp/env.$$
trap "rm -f /tmp/env.$$" EXIT
ssh -t -l "$userarg" localhost /tmp/env.$$
exit $?



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

Re: About the 'su' command

[Larry Hall]

Sylvain Petreolle wrote:

> Do you mean here that the only user who can do 'su' at the moment is
> SYSTEM ??
> 
>>Certainly.  SYSTEM.  But I'd highly recommend using ssh instead of
>>su.  That way you don't have to create a user with privileges that
>>opens a security hole just so you can su.  Of course, you can do
>>so if you prefer.
>>


By default, yes.  It is the only user that's guaranteed to have
the appropriate privileges.  There's been discussions about this
on this list previously if you'd like to know more.


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746


--
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/

Re: About the 'su' command

[Sylvain Petreolle]

Do you mean here that the only user who can do 'su' at the moment is
SYSTEM ??
> 
> Certainly.  SYSTEM.  But I'd highly recommend using ssh instead of
> su.  That way you don't have to create a user with privileges that
> opens a security hole just so you can su.  Of course, you can do
> so if you prefer.
> 


=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) 
ICQ #170597259

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

--
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/

Re: About the 'su' command

[Larry Hall]

Sylvain Petreolle wrote:

>>Really?  Here's two useful and informative messages I found on the
>>first
>>page of hits from google:
> 
> (I used the mailing list serach engine :) but of course google pOwEr )


First mistake. ;-)


>><www.cygwin.com/ml/cygwin-apps/2001-04/msg00051.html>
> 
> Reading the first one and its thread doesnt give a valuable reason to
> keep the FAQ out of sync.


You're welcome to submit a patch.  I offered this thread as "good
background" only.  I wasn't seeking to justify the FAQ's entry.



>><www.cygwin.com/ml/cygwin/2003-02/msg01733.html>
>>
>>Does this not answer your question and provide suitable options for
>>you?
> 
> 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 ?


Certainly.  SYSTEM.  But I'd highly recommend using ssh instead of
su.  That way you don't have to create a user with privileges that
opens a security hole just so you can su.  Of course, you can do
so if you prefer.



-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746


--
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/

Re: About the 'su' command

[Sylvain Petreolle]

> Really?  Here's two useful and informative messages I found on the
> first
> page of hits from google:
(I used the mailing list serach engine :) but of course google pOwEr )
> 
> <www.cygwin.com/ml/cygwin-apps/2001-04/msg00051.html>
Reading the first one and its thread doesnt give a valuable reason to
keep the FAQ out of sync.

> <www.cygwin.com/ml/cygwin/2003-02/msg01733.html>
> 
> Does this not answer your question and provide suitable options for
> you?
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 ?

=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) 
ICQ #170597259

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

--
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/

Re: About the 'su' command

[Larry Hall]

Sylvain Petreolle wrote:

> Hi all developers,
> I want to make some report bout the 'su' command.
> - The FAQ entry about it seems deprecated (or at least not completely
> true)
> 
> This command is shown as removed from the distribution, but according
> to http://www.cygwin.com/packages, it is included in sh-utils-2.0.15-3
> (current version of the package)
> 
> - The 'su' command doesnt work on my WinXP workstation, even if passwd
> succeeded to change my user password.
> Is there some fix known at this moment ? Looking trough the archives
> didnt help me.
> 

Really?  Here's two useful and informative messages I found on the first
page of hits from google:

<www.cygwin.com/ml/cygwin-apps/2001-04/msg00051.html>
<www.cygwin.com/ml/cygwin/2003-02/msg01733.html>

Does this not answer your question and provide suitable options for you?

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746


--
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/

About the 'su' command

[Sylvain Petreolle]

Hi all developers,
I want to make some report bout the 'su' command.
- The FAQ entry about it seems deprecated (or at least not completely
true)

This command is shown as removed from the distribution, but according
to http://www.cygwin.com/packages, it is included in sh-utils-2.0.15-3
(current version of the package)

- The 'su' command doesnt work on my WinXP workstation, even if passwd
succeeded to change my user password.
Is there some fix known at this moment ? Looking trough the archives
didnt help me.

=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) 
ICQ #170597259

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

--
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/