[PATCH 04/10] user namespaces: enforce usernamespaces for file permission
Serge E. Hallyn
serue at us.ibm.com
Fri Aug 22 17:53:04 PDT 2008
Quoting Eric W. Biederman (ebiederm at xmission.com):
> "Serge E. Hallyn" <serue at us.ibm.com> writes:
> > Add a user_ns to the sb. It is always set to the user_ns of the task which
> > mounted the sb.
> > Define 3 new super_operations. convert_uid() and convert_gid() take a uid
> > or gid from an inode on the sb's fs, and attempt to convert them into ids
> > meaningful in the user namespace passed in, which presumably is current's.
> > is_capable() checks whether current has the requested capability with respect
> > to the sb's fs, which is dependent upon the relationship between current's
> > user_ns and those which the sb knows about.
> > If the sb isn't user ns aware - which none are right now - then the new
> > super_operations won't be defined. If in that case current and sb have
> > different user namespaces, then the userids can't be compared.
> > If current's and sb's userids can't be compared, then current will get
> > 'user other' (we usually say 'nobody') permissions to the inode.
> > Changelog:
> > Aug 5: send the whole inode to the super_operations.
> Serge while I am dubious about adding the methods you have added to
> super_block_operations there is one very important question you are
> using them for that we do need to ask.
> Does this filesystem map to user namespace X.
By itself that is not sufficient. We need to support two inodes on the
same fs where both have i_uid=500 on the host fs, while in user
namespace X one is owned by uid 0, and another by uid 1000.
So we need to be able to pass the filesystem an inode and a user
namespace, and ask for the owning uid and gids.
Or am I (I likely am) misunderstanding?
More information about the Containers