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' no longer working?

Corinna Vinschen wrote:
On Jan 9 09:30, Igor Peshansky wrote:
On Mon, 9 Jan 2006, Eric Blake wrote:

According to Igor Peshansky on 1/9/2006 6:04 AM:
Right, that's pretty much what I was asking for above.  Eric, if it
helps, I can look into submitting the patch later this week, though I
haven't looked at the coreutils code in a while, so it might take some
time to understand the specifics.
I've already been playing some with a cygwin-specific patch.  Using the
tips at, I have
already gotten a working implementation that will switch user context on
NT machines with a password.  But I still want to get passwordless
switching working where possible.  The patch should apply to src/su.c
provided in the 5.93-2 source tarball from setup.exe, as a starting
point for your hacking.
Ok, thanks, I'll play around with it...

Speaking of which, I noticed that in my attached patch (work in
progress), I got a failure return for PrivilegeCheck on my NT machine
when run as SYSTEM, even though my understanding is that on NT, SYSTEM
has the privileges of passwordless context switching.  Any ideas what I
might need to fix to make this check more robust, short of just trying a
setuid() to see if it will succeed without first doing the
cygwin_logon_user()/cygwin_set_impersonation_token() check?
Heh, what's wrong with doing that?  If setuid() fails, try it with a
password -- I can't think of any caveats, frankly...  Corinna?

It's fine if su implements password login and trying to call set(e)uid just to check if passwordless login might work is fine, too, but it's a bit off my point.

My point is that Administrators don't have the permissions to do any one
of these actions by default.  You can't change user context unless you
have a service running under a privileged (SYSTEM) account, which starts
the process for you (RunAs, sshd).  The important fact here is that
users working under an Admin account expect that su just works for them,
but it doesn't.

So, whatever you do codewise, be prepared to either add descriptive
messages to su so that users read *why* su might fail for them, or
be prepared to get lots of question on this list (since nobody reads
mailing list archives anyway).

This is a good point. Perhaps this is an argument to change the name of the "working" su to syssu or something and leave the su script as is. Certainly if there's some useful functionality in su in certain cases, it's a shame to mask it completely but it seems reasonable to shield ourselves from those who would use su with expectations and with an itchy email finger. ;-)

Larry Hall                    
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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