From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28847 invoked by alias); 23 Apr 2002 15:51:17 -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 28830 invoked from network); 23 Apr 2002 15:51:15 -0000 Received: from unknown (HELO fs1.in) (64.2.32.210) by sources.redhat.com with SMTP; 23 Apr 2002 15:51:15 -0000 Received: from localhost (rtroy@localhost) by fs1.in (8.11.6/linuxconf) with ESMTP id g3NFpOH15990; Tue, 23 Apr 2002 08:51:24 -0700 Date: Tue, 23 Apr 2002 09:52:00 -0000 From: Richard Troy X-X-Sender: To: Robert Collins cc: Subject: RE: The Cygwin Server Daemon In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg01301.txt.bz2 > > The normal install with setup.exe didn't provide cygserver. > > Correct. This was stated in the development list: the source for > cygserver was only merged in post 1.3.10 being released, so no release > of cygwin has occurred with the cygserver built. I missed that in the archive, though I thought I read _every_ post which contained 'cygserver'. -shrug- > > When you say it > > does very little, I'm still left with the question, "Well, > > what _does_ it > > do?" > > I already answered this. -smile- Perhaps I should have said, "I wish I understood what it does!" > Use cygrunsrv if you want this to happen. > > > + If it's run by a normal user, how does this impart any > > ability to change > > user contexts? (When I asked about assigning privileges, I > > got the short > > answer, "What?") > > Ah, that sort of privilege. Well as it isn't slated to perform user > context changes, that hasn't come up. It certainly could if it ran as a > user with the appropriate access, and the appropriate additional code > was added. Ah, I see. I was perhaps confused because Corinna said in one of the oldest posts on cygserver that "I now know how" to make user context changes. ...There was an implication there, or so I thought! Silly Richard. > > + Regarding my own hopeful use someday: What is a reasonable > > approach to > > adding the honoring of the setuid (and guid) bit(s) in > > image execution? > > Review the _execve code. Create a cygserver message class for use in > that code, and use cygserver to create processes when the set[u|g]id bit > is set. Once the process is created cygserver should return the handle > that CreateProcess returns, and then the _execve code continues as > normal. Ah, a clue. Thank you... ...Since you noticed correctly that I was thinking "a little deep" (most of my OS internals experience is in machine language, assembler, and "Bliss-32"), I could use some clarification here. Here's what I envision at this point: _execve() code notices the suid/guid bits are set, checks that the file owner is not the caller and that the callers group list does not include the files group id, and dispatches a message to cygserver. That message includes the path to the image - and does not include the owner.group as a secondary guard to security at the cost of having to fetch this information a second time. At this point, I presume from your clue that cygserver calls CreateProcess(), passing arguments which tell it to create that process in the context (with the credentials) of the indicated user and group, along with the image name, of course. ...CreateProcess() then returns a "handle" to that process, and returns it to the caller. Or, does cygserver itself switch contexts? (hope not - sounds painful) ...Of course, the caller then returns the handle just as _execve() does. Your thoughts on this are most appreciated. ...If I understand this right, it doesn't sound all that hard! I think I saw code here somewhere that fetches the credentials, and I already have glibc code that pulls user and group info from the system based on the effective user ID of the current process... > cygrunsrv doco - you should just reference the cygrunsrv man page IMO - > rather than recapitulating it in the cygserver doco. Somehow I was confused that they were aspects of the same thing. Oops! > > Server Children: > > > > Regarding the question: Doesn't the implementation imply that > > the server > > must spawn every process? Or at least be the caller of the > > win32 to start > > the process and setup the process<->server communication channel? The > > answer is yes. > > No. The answer is no. Any cygwin process can attach to the server. It > uses standard NT calls to identify the uid and gid of the process. Ah! Well, this was what I got from an honest reading of the archive. Glad you caught that as I was _quite_ curious - which is why I included it in the writeup! > Good work on the collation to date, keep it coming :}. Thanks, Rob, it was a whole lot more work than I would have thought! (And the mail archive being down part of Sunday didn't help! -shrug-) Regards, 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/