help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running custom base servers


From: Ludovic Courtès
Subject: Re: Running custom base servers
Date: Wed, 2 Apr 2003 16:19:47 +0200
User-agent: Mutt/1.3.28i

On Wed, Apr 02, 2003 at 03:40:44PM +0200, Marcus Brinkmann wrote:
> CRASHSERVER should work.  That is, currently core dumping crashes the kernel
> anyway, but at least CRASHSERVER env variable should be honored.

Right, I had forgotten this one.

> EXECSERVER is disabled because of unspecified security concerns.
> 
> Other servers like auth, proc and init are set per-task (see fakeauth for
> example).  I am not sure what the story is with init.

Yes.

> What else is there?  password, socket and defpager.
> Well, ok.  It's probably harmless for those to be overridable.
> Esp socket would be useful, I guess, although I am not sure about the exact
> syntax, as you'd probably want it to be replacable on a per protocol basis.

Yes, I was actually thinking about the socket servers, pflocal and
pfinet.  As you said, we would need a per-protocol environment variable
such as PFINETSERVER and PFLOCALSERVER.  Maybe these variables should
just be ignored for setuid programs.

> Yes, this should work, although it is probably better to make it a default
> feature of the Hurd whereever possible, so just setting environment
> variables works, too.  Note that you must then be more careful about suid
> programs (while in the chroot case suid programs will be taken care of by
> the filesystem they are on, ie the root filesystem - they will not see the
> unionfs at all).

I also feel that it would be better to have glibc check the contents of
these variables rather than to rely on the technique I mentionned which
is less straightforward.

Would it be possible to have glibc changed so that it looks for these
variables before lookup'ing the default servers?  I think that it's an
interesting and useful feature which would be easy to add to glibc.
What do you think?

Thanks,
Ludovic.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]