Will shiftfs help us mount a diskimage with uid:gid mapped

Serge Hallyn (shallyn) shallyn at cisco.com
Thu May 7 17:10:49 UTC 2020


Hey Christian :)  Hey members of kernel-team these days :)

Hey Sarvi,

To be clear, you don't need "a container environment" to use user
namespaces, that is, you don't have to use docker or even lxc to
do what Christian is describing.  lxc-usernsexec is a standalone
program based on the lxc libraries which just makes this easier
than writing your own little program to map userids.

When you say "we then snapshot that workspace", what kind of
snapshot are you talking about?  Is this btrfs?

On Wed, May 06, 2020 at 02:44:20PM +0000, Saravanan Shanmugham (sarvi) wrote:
> Thanks Christian,
>     Ours is not a container environment at the moment. 
>     If I understand username spaces correctly, everything running as user "sarvi" inside the namespace will map to "buildusr".
> This would then allow access to all of "buildusr" environment and filesystems as seen in the container? 
> I presume that includes "buildusr" Home directory, etc.
> 
> In our case, we have a single cloned/mounted workspace(diskimage), mounted at say /witspace/sarvi/myws1
> Not in a container.
> And we want the mapping from user "sarvi" to "buildusr" to be applicable to reads/wriits to that mount point only and have no access to "buildusr" outside of that mount point.
> 
> Thanks for the referral to Serge. I will talk to him as well.
>  
> Thanks,
> Sarvi
> Occam’s Razor Rules
> 
> On 5/6/20, 6:39 AM, "Christian Brauner" <christian.brauner at ubuntu.com> wrote:
> 
>     On Sat, May 02, 2020 at 06:04:05AM +0000, Saravanan Shanmugham (sarvi) wrote:
>     > 
>     > 
>     > Our use case is as following
>     >    1. Our fully built software build workspaces can be 800GB+
>     >    2. We have a nightly build that builds the whole workspace 800GB, done by a generic user "buildusr"
>     >    3. We then snapshot that workspace with snapshotting capability.
>     >    3. We want the developer, "sarvi", to be able to clone from that snapshot and be able to do incremental software build and development in the cloned workspace or the seeded filesystem/workspace.
>     > 
>     > Problem:
>     > All the content, files, directories in the cloned workspace are still owned by "buildusr" and not "sarvi", which causes my builds to fail with permission problems.
>     > 
>     > 
>     > Can shifts help us here ?
>     > 
>     > I am not able to find any documentation on how to I can use shiftfs  to mount a diskimage with the uid:gid mapped.
>     > For example, we have a diskimage contains a file system with full build with all the files owned by "builduser:eng".
>     > I am trying to mount that disk image with a loop device, but want the mount to show all the files in the mount system as owned by "sarvi:eng".
>     > There are no containers in play.  Just linux on baremetal.
>     > 
>     > Can some one provide some pointers on how to enable shiftfs on a linux and use it for the above usecase ?
>     
>     Hey Sarvi,
>     
>     Maybe.
>     But you won't be able to do this without using user namespaces.
>     Though I'm not sure you'd even need shiftfs in that case. Wouldn't it be
>     enough if you created a new user namespace and wrote the following id
>     mappings:
>     
>     0:sarvi:1
>     sarvi:buildusr:1
>     
>     So let's say "buildusr" would be 1001 on the host and "sarvi" would be
>     1000. The you can e.g. use the lxc-usernsexec binary to try this.
>     Compile the following little helper:
>     
>     test.c:
>     int main(void)
>     {
>     	setuid(1000);
>     	execlp("bash", "bash", (char *)NULL);
>     	exit(1000);
>     }
>     
>     and then do (obviously with the correct ids):
>     
>     sudo lxc-usernsexec -m b:0:1000:1 -m b:1000:1001:1 -- ./test
>     
>     All files owned by "buildusr" 1001 on the host should now show up as
>     your user in this user namespace and all writes will show up as
>     "buildusr" 1001 on the host. Wouldn't that work?
>     
>     You should also talk to Serge Hallyn in your org. He can probably help
>     you here as well.
>     
>     Christian
>     
> 


More information about the kernel-team mailing list