RE: The Cygwin Server Daemon

[Richard Troy <rtroy at sciencetools dot com>]

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