Re: [PATCH] private mounts

[Miklos Szeredi]

> > So yes the check fsuid is not the perfect solution.  However let me
> > remind you that neither is the one with private namespace.
> 
> What I'm arguing about is that the fsuid check is obscure (it breaks
> traditional semantics of file permissions [*],

No, the permissions are not visible to any other user.  So there are
no semantics to break.

> it doesn't allow an user to grant access to his user mount to other
> users,

Yes, but that granting must be explicitly acknowledget by the grantee,
to avoid the problems previously discussed.  It's probably something
possible to do with the private namespaces (sending mounts to other
user's namespaces, etc)

> even if the permissions allow that and so on) and it doesn't
> fully solve the problem anyway.

I think I know how to fully solve the problem.  If the user has
permission to ptrace the process in question then he can already do
whatever he likes with that process, so userspace filesystem operation
can unconditionally be allowed.  Otherwise it's no-no by default.

This thread is proving to be ever more useful :)  Thanks everyone!

> For similar reasons, I don't advocate for private namespaces either.
> 
> The cure more likely lies in simple policy rules like the "all user mounts
> belong to /mnt/usr" one, instead of putting dubious policy to the kernel.

I'm keeping policy out of the kernel by making the check optional.
Then the userspace daemon can enforce such policies as /mnt/usr.

I'll prefer the checking one, since, I'm all alone on my machine,
don't want to share anything, but _do_ want to have mounts under my
home directory.  You prefer the /mnt/usr, since you want to share it
with others.  A combination is also possible: the user choses for each
mount which is preferable.

Agreed?

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/