From: "Sam Edge" <sam.edge@ntlworld.com>
To: <cygwin@cygwin.com>
Subject: Re: will bash honor the suid bit or not?
Date: Wed, 17 Apr 2002 23:57:00 -0000 [thread overview]
Message-ID: <003801c1e6a1$e0706530$45b0fc3e@nori> (raw)
In-Reply-To: <Pine.LNX.4.33.0204171951080.1389-100000@denzel.in>
> 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/
next prev parent reply other threads:[~2002-04-18 6:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-17 19:36 Richard Troy
2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc)
2002-04-17 21:44 ` Richard Troy
2002-04-17 23:57 ` Sam Edge [this message]
2002-04-18 1:57 ` Corinna Vinschen
2002-04-18 7:35 ` cygwin mentors? Was: bash and the suid bit Richard Troy
2002-04-18 7:49 ` Corinna Vinschen
2002-04-18 8:52 ` Richard Troy
2002-04-18 12:26 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003801c1e6a1$e0706530$45b0fc3e@nori' \
--to=sam.edge@ntlworld.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).