Re: su - coreutils?

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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@cygwin.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/