help-hurd
[Top][All Lists]
Advanced

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

Re: /servers/socket/2 -- why only one inet socket?


From: Marcus Brinkmann
Subject: Re: /servers/socket/2 -- why only one inet socket?
Date: Sat, 12 Oct 2002 17:19:26 +0200
User-agent: Mutt/1.4i

On Fri, Oct 11, 2002 at 10:57:22AM +0200, Niels Möller wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > For this, you could probably use a virtual root filesystem that
> > redirects all access to /servers/socket/2 to ~/servers/socket/2
> > (such tricks can be done [soon?] with shadowfs for example] Or you
> > could try a chroot approach. Or you compile a private glibc with a
> > hacked up <hurd/paths.h>.
> 
> I think it would be a good thing to have environment variables for
> overriding all paths in <hurd/paths.h>. Some of the servers already
> have that, right? (Some or all must probably be ignored for setuid
> programs).

Yes, definitely.  We do this for CRASHSERVER, there is disabled code to do
it for EXECSERVER, and in general it is a good idea.

The problem is security.  For example, up until recently, CRASHSERVER was
honored by suid programs, a grave bug that Roland fixed on my notice.  For
EXECSERVER, it is not clear that all security issues are resolved (see
S_exec_exec in exec/exec.c.

For socket servers, the simples thing to do would probably be to allow to
override _SERVERS_SOCKET (eg "/servers/socket/" in glibc/hurd/hurdsock.c)
with SOCKETSERVERS for non-suid programs.  But that would apply to all
sockets, so you would have to put symlinks or firmlinks for the ones you
don't want to override.  Not too bad, but also not perfect.   Having
PFINETSERVER, PFLOCALSERVER etc and check them according to the protocol
family number is a bit more work, but also more userfriendly.  All of this
under the premise that this is a safe thing to do.

> > The nice thing about the Hurd is that this has nothing to do with the
> > kernel.
> 
> Except that one wants some things like an ethernet device driver that
> does the Right Thing when several pfinet processes uses it at the same
> time.

Well, that is a different type of problem.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

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