This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: su - coreutils?

Corinna Vinschen schrieb:
On Oct 17 22:43, Reini Urban wrote:
I've taken Mark's coreutils patches, the proposed fileutils patches, and some of Bas latest patches (ignore errors) and tried to build a package.
Builds fine, just some fixes for setuid processing in make install need to be done. (for su)

But while we are here some questions, mostly to Corinna:
ok, su was never ported to cygwin. I did read the archives, esp.

Idea: Logon as Administrator, not as SYSTEM.
But if already SYSTEM avoid asking for passwords.
And use the login cygwin_logon_user() code.

But: cygwin_logon_user always fails, even in a sysbash.

Hmm, it works in login(1) and in ftpd(8), right?

Thanks. That's the list I wanted to hear.
No, it didn't work there. After enabling the user login(1) works ok from SYSTEM (a sysbash).

However, this isn't really su functionality since you need special
user rights which the standard user (even admin) doesn't have.  The
su functionality always needs a server application which has the
permissions to create a new user token one way or the other.

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.

And, how to support empty password accounts?
cygwin_logon_user fails with set_errno(EINVAL);

Is the account disabled, perhaps? Please note that there are additional Windows security settings which you have to take into account.

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

Can we use subauth/cygsuba.c then?

No. It's dead, Jim. It's kept for historical purposes (like, say
excavations of temples of the Cygwin sect in 1000+ years).

Indeed, looked like a prehistoric MSDN-style excavation.

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

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.

Replace GINA? But would people use that? Maybe.
Isn't there some sample GINA code to use in MSDN?
Haven't got that lately.
Reini Urban

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]