Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
Date: Mon, 18 Oct 2004 15:47:57 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: su - coreutils?
Message-ID: <20041018134757.GG26101@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20040401165235 DOT GF2598 AT cygbert DOT vinschen DOT de> <406C7928 DOT 9070708 AT fangorn DOT ca> <20040402073643 DOT GI2598 AT cygbert DOT vinschen DOT de> <406D6453 DOT 20104 AT fangorn DOT ca> <20040402141222 DOT GA14036 AT cygbert DOT vinschen DOT de> <20040402160030 DOT GD1144 AT coc DOT bosbc DOT com> <406DAD0C DOT 6090402 AT fangorn DOT ca> <4172D969 DOT 8040107 AT x-ray DOT at> <20041018105734 DOT GB26101 AT cygbert DOT vinschen DOT de> <4173BBE8 DOT 6060700 AT x-ray DOT at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4173BBE8.6060700@x-ray.at>
User-Agent: Mutt/1.4.2i

On Oct 18 14:49, Reini Urban wrote:
> Corinna Vinschen schrieb:
> >I would omit su from coreutils.  There's no gain to support it in a
> >windows environment.  The functionality is a subset of what a local
> >sshd installation allows, but with more security implications.
> 
> su could check for a local sshd daemon running and try a local ssh
> session then. looks like a larger hack.
> [...]
> But despite all limitations it sounds useful to have.
> Compared to removing su(1) from coreutils.
> 
> If called from a unprivileged account it should not print
> "su: incorrect password", just something like "cannot setuid", or
> "can only setuid as SYSTEM".
> 
> Same for login(1). Even with correct password it prints "Login 
> incorrect", if the password is correct or incorrect. I would vastly 
> prefer printing a better error message on a correct password. Same as 
> for su(1).

login(1) is used in the context of telnet/rlogin only and that's documented
in /usr/share/doc/Cygwin/login.README.  The problem is simply that you don't
know why cygwin_logon_user resp. LogonUserA failed.  The return value is an
invalid token and errno is set to EINVAL.  IMHO that's enough.  If somebody
(again) reports that login doesn't work on the command line, you can easily
point this person to the README, the mailing list archive, the FAQ and to
using ssh.

su(1) has a very specific purpose which it can't satisfy under Windows.
It only works as you expect when running under SYSTEM.  But to become
SYSTEM, one already has a server process running which has the appropriate
rights.  Why not use the same server process to become another user
temporarily?

I just had a vague idea, that it might be useful to implement su(1) as
a stub, which only prints that it can't work as the user expects and
where to get information on how to get a similar functionality using 
the existing tools.

However,


> >If we ever get the input for how to create a real authentication module,
> >we can probably resurrect parts of the existing code.
> 
> That would be really great! How?

I don't know.  If I knew, I would have created a Cygwin auth module
at least two if not three years ago.

> I thought about a cygserver extension to change the security tokens for 
> processes: su(1), sudo(1), but generally seteuid(3) calls and setuid 
> (u+s) scripts.

Using cygserver would be the way to go, basically (but has nothing to do
with LSA authentication modules) and ...

> Also PAM and/or NSS support in cygserver would be really cool.
> NSS only needs to be added to libc (How do the newlib folks think about 
> that? NIS was not accepted AFAIK),
> PAM and generic set{,e}uid(3) would need a cygsspi.dll (Security Support 
> Provider Interface), used by cygserver probably.

... this sounds cool but of course, http://cygwin.com/acronyms/#SHTDI


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

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