This one is for the archives... On Unix/Linux, there's a feature that provides security for applications which require access to privileged data by unprivileged users called the suid bit. This bit is set on a per-executable basis and is stored in the file system. It directs the "exec" system call to run the executable as the owner of the file, not as the user who called the program. (Note that this is distinctly different than programs that call the setuid system call, though surely any given executable could do either or both.)
When porting such applications to Windows, there's a problem because Windows has a considerably different mechanism. Cygwin honors the suid bit in the file system but the feature that implements 'exec' does not. Until that is resolved, ported programs that need to provide reasonable security from Windows users who are not fully privileged have to use another mechanism. The following describes one such method using "SSH." If sshd is installed, the application can be called using the ssh client. To set it up, create a new user account for this application that will be "disabled" but will be used exclusively for the purpose of this workaround. Importantly, this account must have a directory that's protected somewhere and is not shared by another account since ssh configuration files should be kept separate. Grant it whatever group privileges make sense for your security strategy. Be sure this account is created either before Cygwin is installed, or be sure to run mkpasswd/mkgroup, as directed elsewhere in Cygwin literature. This ensures the account is known to Cygwin. Install the Cygwin sshd, too, which you can do at the same time you install Cygwin if you wish. Create null pass-phraise keys for the application account that let any user with the right key login without a password. Distribute this key to all authorized users of the program and set it up in their environs according to ssh's directions. Create a helper program that will launch your application. The helper program is pointed to in Cygwin's /etc/passwd for the application account instead of the shell (usually /user/bin/bash). When called from ssh, it will receive two arguments, one is just '-c' and the other is the complete command line. Your helper program will have to reformat the arguments as required by your application and then do an exec call to execute the desired, unmodified application. You are now ready to setup lanuching the application. There are many ways, such as creating an alias something like this: $ alias <application>='ssh <application_account>@localhost -c ' Whatever is typed after the alias will be appended to the line and become arguments to your application. There remains an important issue: Unlike a genuine suid-bit launched program, in this scenario the environment is lacking in information about the genuine authenticity of the launching user - what system are they on and what is their username are important among these. Providing a scheme for resolution of this problem is a bit beyond the scope of this whitepaper, but the interested reader can probably invent something clever, perhaps with the use of more sophisticated helper programs on both ends. Here are a few additional thoughts regarding the missing information. One idea is to use "identd". Unfortunately, identd is not currently an available package for Cygwin. You could just pass information along from the original user as a flag ( -U <username>@<hostname> for example) but knowing that it's genuine is a bit of a trick. In such cases, I recommend encrypting the username and hostname and then have the helper explicitly check that the connection is in fact local and set the username in the environment before calling the application. Also, if the application account has SYSTEM privilege, it may then change users, and this may be a desireable trait to consider in your helpers. Regards, Richard -- 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/
