From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Richard Troy" <rtroy@sciencetools.com>, <cygwin@cygwin.com>
Subject: RE: The Server Daemon
Date: Sat, 20 Apr 2002 23:02:00 -0000 [thread overview]
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5EA8@itdomain003.itdomain.net.au> (raw)
> -----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/
next reply other threads:[~2002-04-21 5:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-20 23:02 Robert Collins [this message]
2002-04-20 23:14 ` Christopher Faylor
-- strict thread matches above, loose matches on Subject: below --
2002-04-20 10:42 Richard Troy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FC169E059D1A0442A04C40F86D9BA7600C5EA8@itdomain003.itdomain.net.au \
--to=robert.collins@itdomain.com.au \
--cc=cygwin@cygwin.com \
--cc=rtroy@sciencetools.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).