Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> 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? -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers