[Top][All Lists]

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

Re: feature-mtab-translator (v3)

From: Justus Winter
Subject: Re: feature-mtab-translator (v3)
Date: Fri, 19 Jul 2013 18:04:47 +0200
User-agent: alot/0.3.4

Quoting Richard Braun (2013-07-19 17:41:55)
> On Fri, Jul 19, 2013 at 05:25:02PM +0200, Justus Winter wrote:
> > Richard mentioned that revealing mount points does not seem to be a
> > concern on Linux, but arguably on Hurd an active translator is more
> > common than a mount on linux.
> Well, that's irrelevant. What matters is that on Linux, mount points are
> under the responsibility of the administrator, even when owned by users
> (which is a simple case of delegating responsibility), whereas on the
> Hurd, any user can attach translators.
> You claim that this patch series fixes all security issues raised by
> Neal, but I'm not sure it does. As you say, getting child translators
> checks the permissions of the requesting client, but as you also say,
> a translator running as root can access the complete list, which is
> what is done when accessing /proc/mounts, I suppose. Ideally (but
> I'm not sure how to properly do it so it's simply FYI), the translator
> should be able to act on behalf of its users, getting the list of
> translators using their credentials, i.e. user bob reads /proc/mounts
> and all fsys_get_children RPCs done in that context uses bob's identity.
> Correct if I'm wrong, but I think it's still a valid security concern,
> worth mentioning here.

My personal preference would be to run the translator on /proc/mounts
as unprivileged user created solely for this purpose by default. It's
up to the system administrator to change that if he wishes. I know
it's not as magically as it could be if the mtab translator would
impersonate the requesting user, but then again, this is no problem of
the RPC procedure or the server side implementation of it.


reply via email to

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