From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9527 invoked by alias); 18 Apr 2002 06:25:52 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 9518 invoked from network); 18 Apr 2002 06:25:51 -0000 Received: from unknown (HELO mta01-svc.ntlworld.com) (62.253.162.41) by sources.redhat.com with SMTP; 18 Apr 2002 06:25:51 -0000 Received: from nori ([62.252.176.69]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020418062549.ELUZ14788.mta01-svc.ntlworld.com@nori> for ; Thu, 18 Apr 2002 07:25:49 +0100 Received: from 127.0.0.1 (FROM= HELO=nori) by nori (62.252.176.69) with SMTP (DimWit 0.92) id <20020418062547.0000.nori@nori> for ; Thu, 18 Apr 2002 06:25:47 +0000 Message-ID: <003801c1e6a1$e0706530$45b0fc3e@nori> From: "Sam Edge" To: References: Subject: Re: will bash honor the suid bit or not? Date: Wed, 17 Apr 2002 23:57:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2002-04/txt/msg00925.txt.bz2 > 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 acco= unt 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=3D" 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.=20 The way it's normally done on NT is by installing a service - a special typ= e of application that runs under the NT Service Manager susbsystem. (This i= s 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 proces= ses 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.=20 Under UNIX-like systems it's not bash that modifies the UID/GID of the crea= ted process but the operating system when asked to exec() a file with the a= ppropriate suid/sgid bit set. Non-superuser processes can't call setXid() with an ID other than one of th= eir own anyway. If they try, the call fails with errno =3D=3D EPERM. (Other= wise any user could write a program that runs with the priveleges of any ot= her!) > Perhaps it should become a service? I dunno! LOL. It's certainly not a good idea to start making major architectural cha= nges 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 t= o split the program into a client application and a non-Cygwin-based server= service and have them communicate via whatever IPC mechanism with which yo= u're happy. If you used TCP/IP sockets the client could remain a Cygwin app= lication and you would be able to write a UNIX version of the server at som= e 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 u= ses 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 proces= ses have access to shared memory resources and can compromise each others i= ntegrity. --=20 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/