suid bit on executables?

Igor Pechtchanski
Wed Mar 24 03:09:00 GMT 2004

On Tue, 23 Mar 2004, Richard Troy wrote:

> Hi Igor,
> Interesting dialogue, but you seem to be mising one CRITICAL point, which
> I apparently didn't make clear: It is absolutely unacceptible to have the
> user of the software in question know any password other than the one for
> their own account or otherwise have access to privileges they're not
> supposed to have (through ssh keys, for example). The objective of the
> exercise is to find a way to enforce "proper" security.


Then this won't work - installing a service can only be done by someone
with a "logon as service" privilege.

> Therefore, installing as a service with a password is entirely
> acceptible because it's done by a system administrator type person who
> _has_ the appropriate privilege...

Oh, I see the misunderstanding here.  I actually meant installing *and*
using the service right away.  If you wanted to have a service that always
runs and, when accessed by any user, opens a new window with a particular
application in it (running as someone else), you're really better off with

> That said, the _LAST_ thing I'd want is to have a privileged console
> program come up and provide _any_ access whatsoever! ... Anyway, your
> suggestion about /dev/conin and /dev/conout may well be on the right
> track. Here might be a reasonable solution:
> $ cygrunsrv --install <my_service> --path <path_to_my_program.exe>
>  --args "<my_programs_args> </dev/conin >/dev/conout 2>/dev/conout"
>  --env <my_progs_env_vars> --username <proper_prived_account>
>  --password <proper_prved_accounts_passwd> [other cygrunsrv args]
> ...While typing all these emails, I've been trying to do just this!
> However, I've had to reboot a couple of times, and am otherwise slowed
> down a little. -frown- The key here is, from the command line, how does a
> user fire off a connection/dialogue with the installed program/service? My
> bet is, though, that this isn't possible, since you go on to state:

Exactly.  I was thinking of a way of having a somewhat privileged user
execute a program as someone else, with no concern for the security of
your system (which isn't much on Windows anyway).

> > conin/conout will let the process access the console that cygrunsrv pops
> > up, rather than the stdout/stderr file descriptors, which are redirected
> > to files in /var/log...
> ...and I very surely don't want any popup console!
> > Technically, you should have been able to look at
> > <> instead...
> Thanks for the pointer...
> > The Cygwin User's Guide makes for wonderful and exciting bed-time
> > reading. ;-)
> (At one point, about 3 years ago, I actually read all available Cygwin
> documentation "cover to cover. -Yawn!-  )
> > However, the above document is strangely silent on the topic of
> > conin/conout...  As things stand now, looking at the Cygwin source is
> > probably your best bet.
> ...Hopefully that won't be necessary! I take it that conin and conout are
> "console in" and "console out", respectively, though I don't yet see how a
> user at a bash prompt, for example, hooks up with the installed program.
> If that can be done, I'd MUCH rather this solution than to use ssh...

I think, given what you said above, that sshd is your best bet,
unfortunately, until cygserver can do suid.

> > Yes, except you'd probably need to redirect the stdout to /dev/conout as
> > well.
> As above, maybe?
> > Yes, cygrunsrv allows services running explicitly as some user, with two
> > caveats: they can't be interactive, and you'd need to enter a password for
> > that user.  The above method will let you switch the context with no
> > password, thus emulating the "suid" functionality.
> I got errors when I tried to use the --interactive flag as found in your
> example, and -h didn't show it, either! -smile- Oh well...

Do you have the latest version of cygrunsrv?

> > All the password checking, etc, is superficial.  The point is that there
> > exists functionality that lets any user, no matter how unprivileged, to
> > switch the context to that of any other user, as long as the appropriate
> > permissions are verified (e.g., the user knows the root password).
> Well, I don't think the password checking is superficial at all! I'm just
> trying to let the "unprivileged user" have access to functionality
> (provided by a special program) without having access to the actual raw
> data (as used by that special program). ...The system administrator sets
> up that special data and special program... The "unprivileged user" must
> remain that way!

The password checking is an important part of the whole process, but is
completely orthogonal to the user context switching functionality.

> > I didn't say that having this functionality is a security hole, I just
> > said that in Windows, a user context switch is not possible from all user
> > accounts unless special privileges are assigned to all user accounts,
> > which *would* open a security hole.
> I sure hope you're wrong as that's what this whole exercise is all about!
> We want a user context switch to a new user without having to give extra
> privileges to anybody!

Again, sshd allows this.  The way it allows this is by running as a
privileged account (SYSTEM), and allowing non-privileged accounts to
communicate with it.  FWIW, I think that, if you plan to provide your own
service for the suid functionality, you'll be rewriting substantial parts
of either sshd or cygserver (or both).

> I suspect that we're in violent agreement, it's just that you've perhaps
> misunderstood what I was after. -shrug-
> And again, thanks for the dialogue...
> Richard

      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list