This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: The Server Daemon




> -----Original Message-----
> From: Richard Troy [mailto:rtroy@sciencetools.com] 
> Sent: Sunday, April 21, 2002 3:05 AM
> To: cygwin@cygwin.com
> Subject: The Server Daemon
> 
> 
> 
> Hi All,
> 
> So, I'm trying to get started with implementing the honoring 
> of the suid bit by cygwin. I've downloaded the source and 
> performed a build (which failed - the tail of make.log is 
> below). So, I jumped into the source directory and looked at 
> what was there. I started with the cygserver* files, as, if 
> I'm not mistaken, that's where I'd need to be working... I 
> went on to read the ROADMAP and most how-*.txt files, 
> exec.cc, and other important looking files.

Ignore the cinstall failure, it's irrelevant to what you are doing.
 
> There were a number of things in there that I _didn't_ see, 
> most notably 
> some documentation on the intended architecture of the 
> daemon/server. I 

That's mainly in mailing list archives at the moment.

> didn't find any working copies of it either. 

What do you mean by this? It works for me, and the other folk who tested
it before it got committed. Currently it does very little though.

> ...In reading the code, it's clear to me that I need some help
understanding the 
> architecture. What is 
> this code intended to do? Is it intended to move the cygwin 
> shared memory 
> into a protected environment to close the existing security 
> hole? 

The cygwin shared memory isn't a security hole so much as the granting
of memory read access to every process is! That's the first thing that
the daemon address's. The second thing is a partial sysVshm/ipc
implementation.

Essentially you add a new object type to the server and to the client
(which is in cygwin), and make requests using that object type when you
need to have the server do something.

> Or, just 
> what were the motives for creating it? 

This is well covered in the cygwin-developer mailing list archives.

> What's its development 
> status? 

Likewise. Well maybe some enlargement would be useful. The core daemon
is functional and stable. There is additional work that can be done to
expand it as a framework for specific goals, but there is no reason you
cannot write any client-server code you desire using it now.

> I noticed comments about not being thread-safe in parts - 
> what's up with that? 

Just what it says. There are things that <may> need to be thread safe
that are not. If it's in the sysV code, you can ignore that because it's
not exposed to client applications yet, and the threading will be
address'd before it is.

> There's talk of running two instances simultaneously 
> someday - how does that fit into development plans? 

Where is that talk? There are no plans to run multiple instances of the
daemon concurrently. (Except in the context of terminal server machines,
where one daemon per user may be desired).

> How is it installed and 
> loaded? 

c:\cygwin\bin\cygserver from a cmd box. Or even via cygrunsrv.

> How do I give it privileges?

Huh? 
 
> And, as an asside, comments about things like this would be 
> great to have in the source code itself!

The core concepts should be in the code.
 
> Yes, I could write the individuals mentioned in the source, 
> but Corinna 
> dictated that we should keep our dialogues here. In deference 
> to her, I'm 
> posting here...

I appreciate this too. 

Rob

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]