The Server Daemon

The Server Daemon

[Richard Troy]

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.

As a recap, what I need from cygwin is the honoring of the suid bit, so 
that execution of an image with this bit set is executed in the context of 
the user identified in the file system as owner. I'd also be happy with 
any other alternative which lets my application code run in a security 
context other than that of the user without having to give that user any 
special privileges.

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 
didn't find any working copies of it either. ...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? Or, just 
what were the motives for creating it? What's its development status? I 
noticed comments about not being thread-safe in parts - what's up with 
that? There's talk of running two instances simultaneously someday - how 
does that fit into development plans? How is it installed and loaded? How 
do I give it privileges?

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

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

Your input greatly appreciated.

Richard


___ Tail of make.log ___


c++ -L/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup -L/d/d1/RT/cygwin/obj/i686-pc-cy
gwin/winsup/cygwin -L/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup/w32api/lib -isyst
em /d/d1/RT/cygwin/src/winsup/include -isystem /d/d1/RT/cygwin/src/winsup/cygwin
/include -isystem /d/d1/RT/cygwin/src/winsup/w32api/include -isystem 
/d/d1/RT/cygwin/src/newlib/libc/sys/cygwin -isystem /d/d1/RT/cygwin/src/newlib/libc/sys/cyg
win32 -B/d/d1/RT/cygwin/obj/i686-pc-cygwin/newlib/ -isystem /d/d1/RT/cygwin/obj/
i686-pc-cygwin/newlib/targ-include -isystem /d/d1/RT/cygwin/src/newlib/libc/include -MMD -g -O2 -mno-cygwin -I. -I/d/d1/RT/cygwin/src/winsup/cinstall 
-I/d/d1/RT/cygwin/src/winsup/mingw/include  -I/d/d1/RT/cygwin/src/winsup/bz2lib 
-mwindows -c -o mklink2.o ../../../../src/winsup/cinstall/mklink2.cc
../../../../src/winsup/cinstall/mklink2.cc: In function `void 
make_link_2(const char *, const char *, const char *, const char *)':
../../../../src/winsup/cinstall/mklink2.cc:24: cannot convert 
`CLSID_ShellLink' from type `const GUID' to type `const CLSID *'
../../../../src/winsup/cinstall/mklink2.cc:25: cannot convert `IID_IPersistFile'
 from type `_GUID' to type `const IID *'
make[2]: *** [mklink2.o] Error 1
make[2]: Leaving directory `/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup/cinstall'
make[1]: *** [cinstall] Error 1
make[1]: Leaving directory `/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup'
make: *** [all-target-winsup] Error 2

Any ideas what went wrong?

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

Re: The Server Daemon

[Christopher Faylor]

On Sun, Apr 21, 2002 at 03:46:38PM +1000, Robert Collins wrote:
>>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.

And, see also: http://cygwin.com/bugs.html

cgf

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

RE: The Server Daemon

[Robert Collins]

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