Re: [PATCH -mm 5/7] add user namespace

Serge E. Hallyn
2006-07-14T17:06:25Z

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> Dave Hansen <haveblue@us.ibm.com> writes:
> >>
> >> > On Thu, 2006-07-13 at 21:45 -0600, Eric W. Biederman wrote:
> >> >> I think for filesystems like /proc and /sys that there will normally
> >> >> be problems. However many of those problems can be rationalized away
> >> >> as a reasonable optimization, or are not immediately apparent.
> >> >
> >> > Could you talk about some of these problems?
> >>
> >> Already mentioned but. rw permissions on sensitive files are for
> >> uid == 0. No capability checks are performed.
> >
> > As Herbert (IIRC) pointed out that could/should be fixed.
>
> Capabilities have always fitted badly in with the normal unix
> permissions.

Well they're not supposed to fit in.

If we keep permchecks as uid==0 on files which invoke kernel callbacks,
then we can only say once what root is allowed to do. If we make them
capability checks, then for differnet uses of namespaces we can have
them do different things. For instance if we're making a separate user
namespace for a checkpoint/restart purpose, we might want root to retain
more privs than if we're making a vserver.

Look I just have to keep responding because you keep provoking :), but
I'm looking at other code and don't even know which entries we're
talking about. If when I get to looking at them I find they really
should be done by capabilities, I'll submit a patch and we can argue
then.

> So if we have a solution that works nicely with normal
> unix permissions we will have a nice general solution, that is
> easy for people to understand.
>
> What I am talking about is making a small tweak to the permission
> checking as below. Why do you keep avoiding even considering it?

Not only don't I avoid considering it, I thought I'd even suggested it
a while ago :)

It sounds good to me.

-serge