Mail Archives: cygwin/2002/04/23/07:00:15
> -----Original Message-----
> From: Richard Troy [mailto:rtroy AT sciencetools DOT com]
> Sent: Tuesday, April 23, 2002 6:25 AM
> In doing this compliation and write up a lot of questions yet
> remain for
> me. There are just a whole lot of loose ends. It's my casual
> observation
> that the emails in the archive weren't as helpful and clear
> to me as they
> might have been because the original email audience knows
> each other and
> come from similar backgrounds so they don't need as many words to
> communicate an idea. Frankly, the code moved from losely
> sketched concept
> to running code without much discussion of the architecture. I, on the
> other hand, need a little more detail to really get it.
That's a usual corollary of a single developer creating something.
> 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.
> When you say it
> does very little, I'm still left with the question, "Well,
> what _does_ it
> do?"
I already answered this.
> And, the new cygwin1.dll was _huge_ in comparison to the
> previous
> one. Is that because of debugging info?
Yes.
> Other important open questions include:
>
> + Why doesn't the cygserver run, itself, as a server under NT
> much as sshd
> 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.
> + 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.
> the file access occurrs to bring in the executable image, there's a
Too low level - we don't directly map in the image ourself - we use
CreateProcess.
...
cygrunsrv doco - you should just reference the cygrunsrv man page IMO -
rather than recapitulating it in the cygserver doco.
> 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.
Good work on the collation to date, keep it coming :}.
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/
- Raw text -