Mail Archives: cygwin/2004/03/23/13:56:18
Igor,
one of us is confused! ...NOT referring to Cygwin, but Unix in general:
'su' requires the caller to either already be root, or have the password
of the account they want to "become". In contrast, there's no checking of
passwords at all when a program is launched that has the suid bit set: It
simply starts in the context of the files owner. The user may well be
unaware, even, that a different user id is involved - not at all the case
with su, where it's explicit.
BTW, tnx for the pointer to ntsec, but that's old hat for me: I have for
many years been aware of this issue, though I'm far from a guru. As for
those "security holes" - that's what we're trying to work through in this
dialogue: I have a legitimate need, we can see the "right" answer is to
have cygwin1.dll perform execs that honor suid - perhaps with the aid of
cygserver, and that at the moment we are discussing a workaround for the
interrim! -smile- ...And _THANK_YOU_VERY_MUCH_ for your participation in
this dialogue!
Anyway, back to my question you neatly avoided! -smile- If the program
were installed with cygrunsrv and the user flag specified the right user,
can conin and conout be used to get the "command line" access to the
running program? I gathered that's what your example using conin and
conout were really all about, not su.exe - we _know_ that's "broken!"
Maybe take a second look at my post on my interpretation of your
suggestion and see if I've gotten it right?
Regards, and thanks again,
Richard
> > No, what I need is _very_ different. The requirement is for a program that
> > runs as a different user without that user having any special privileges
> > themselves and without the ability to log in, or run other programs as
> > that other user. On Unix (and Unix clones), there's a concept of the "suid
> > bit" which is set in the file system and associated with executable
> > programs (and on many implementations, executable shell scripts too). When
> > any user, including root, executes a program with the suid bit set, the
> > program runs just like any other program except that it runs in the user
> > context of the file's owner, NOT as the user who called the program. In
> > contrast, su requires that the caller have the password of the account in
> > question...
> >
> > That said, a "working su" program _should_ be able to be used as the
> > foundation of an implementation of an exec call where the suid bit is set.
> > Corinna hinted that W2003 makes things harder and I haven't any idea why,
> > but it figures that Windows would try very hard to ensure that nothing
> > else is compatible with Windows. -frown-
> >
> > Regards,
> > Richard
>
> Richard,
>
> The functionality of "su" and the "suid bit" is the same. Aside from
> privilege checking, both require the ability to have any user set its
> effective user id to that of another user. This is currently not possible
> in Windows without opening a whole set of security holes. By default, the
> only account able to switch user contexts is SYSTEM. Reading
> <http://cygwin.com/cygwin-ug-net/ntsec.html> should provide some insights.
> Win2003 makes it harder because the appropriate privileges aren't assigned
> to SYSTEM by default, as they were in the previous versions of Windows.
> HTH,
> Igor
>
--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy AT ScienceTools DOT com, 510-567-9957, http://ScienceTools.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/
- Raw text -