will bash honor the suid bit or not?

[Richard Troy <rtroy at sciencetools dot com>]

Hi All,

I've got an application I'm trying to port from Unix to cygwin on Windows
NT/2000 using NTFS.

The application consists of an executable and a few configuration files.
To work correctly, the executable and configuration files need to be owned
by any ole user which is _not_ the user who wishes to run the application.
Root/Administrator privileges are _not_ required, or desireable. The
config files and executable are then secured from the user being able to
change them, or view the configuration files. The suid bit of the
executable is set in the file system. When the user runs the program,
bash, or whatever shell, should then note the suid bit and run the program
in the user context of the file owner, not the user who executes the
program. The application thereby has access to the config files that the
user does not ordinarily have.

The program does not call, and does not need to call setuid(), nor any
other flavor of such a call.

The program works just fine on every Unix and Linux system upon which it
has so far been tried. Now for Windows NT/2000! In setting it up and
testing, I found that it runs properly for the user who owns the
executable and configuration files. However, if another user tries to run
it, it fails.

In reading up, there's talk of the cygwin dll having a setuid() function,
so I don't understand why the cygwin bash shell doesn't honor the setuid
bit. I also observe that the file system _appears_ to honor the concept of
the setuid bit. That is to say, you can $ chmod u+s <file>, and
$ls -l <file> also shows the bit being set (or cleared as the case may
be). ...SO... If the cygwin bash doesn't honor the bit, why bother having
it available? (I didn't see this on the "to do" list.)

It occurrs to me that there's a section in the User's Guide, which I
didn't quite understand, that talks about "special permissions." In
particular, it states:

   "NT uses so called `access tokens' to identify a user and it's
   permissions. To switch the user context the application has to request
   such an `access token'. This is typically done by calling the NT API
   function LogonUser. The access token is returned and either used in
   ImpersonateLoggedOnUser to change user context of the current process
   or in CreateProcessAsUser to change user context of a spawned child
   process. An important restriction is that the application
   using LogonUser must have special permissions"

How to set these special permissions is not discussed, and it merely
begins describing how to write a setuid call - or, rather, replace it?
...Either way, it's my (barely educated) view that BASH should recognize
that the suid bit is set for the about-to-be-executed image and should
place the call to CreateProcessAsUser on our behalf... This would avoid
-any- coding changes whatsoever. It would be _very_ useful, too!

So... Do I merely have to set special permissions on the application
program somehow? If so, pray-tell how? Or, is there no solution today? If
there's no solution, since I _have_ to solve this, should I take it upon
myself to contribute a tiny piece of code that implements this that could
later be rolled into the cygwin-bash? (Please note that I don't really
feel competent to write such code! I have _never_ written _any_ "Windows"
application code!)

Inquiring minds - and creative and demanding hackers - need to know!

...Thanks in advance for your time!

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/


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