Re: will bash honor the suid bit or not?

["Sam Edge" <sam.edge@ntlworld.com>]

> And you were right to guess that I already set ntsec in CYGWIN - it was my
> first move. That, and to put the definition in the systems env. vars, so
> other users who log in without Administrator privilege can't change it.

I also set the CYGWIN environment in the "system variables" section of the NT configuration simply so that I can run Cygwin executables under any account without having to worry about it.

However, this doesn't prevent ordinary users from changing its value prior to running Cygwin programs. Open an NT command prompt (CMD.EXE), type "SET CYGWIN=" and then "bash" and you'll see.

> I am apparently ignorant of how to handle a case like this on NT/2000, nor
> do I even know where to look. This problem must be solved for many uses
> already. I would think that a great many services have this same problem.
> It's an exceptionally common need to have a non-privileged user run a
> program and get privileged results. 

The way it's normally done on NT is by installing a service - a special type of application that runs under the NT Service Manager susbsystem. (This is designed for processes that run independently of interactive users. It's used to implement the equivalent of UNIX daemon processes and other "system" facilities.)

The service runs as SYSTEM or some other priveleged account and user processes use IPC to access its facilities in a controlled manner.

> From where I sit, it sure looks like this problem should be solved for the
> BASH shell. 

Under UNIX-like systems it's not bash that modifies the UID/GID of the created process but the operating system when asked to exec() a file with the appropriate suid/sgid bit set.

Non-superuser processes can't call setXid() with an ID other than one of their own anyway. If they try, the call fails with errno == EPERM. (Otherwise any user could write a program that runs with the priveleges of any other!)

> Perhaps it should become a service? I dunno!

LOL. It's certainly not a good idea to start making major architectural changes in the shell program!

> It'd be great to hear from more of you: Anyone else care to confirm
> Larry's suggestion that giving privileges to users is the solution in this
> case?

If it's a security application then no. A better solution for NT would be to split the program into a client application and a non-Cygwin-based server service and have them communicate via whatever IPC mechanism with which you're happy. If you used TCP/IP sockets the client could remain a Cygwin application and you would be able to write a UNIX version of the server at some point too. An NT-specific solution might find RPC more appropriate though.

You could write a standard UNIX-style daemon as a Cygwin application that uses sockets and install it as an NT service using cygrunsrv but this isn't a secure solution. The Cygwin documentation tells us that all Cygwin processes have access to shared memory resources and can compromise each others integrity.

-- 
Sam Edge


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/