--overlay mode has empty home dir

[dshmgh]

I am using 0.9.36 tarball and building on a 32 bit Mageia 5 system kernel 4.1.15-desktop586-2.mga5 My setup has a separate mount point for /home. When the overlay is mounted (in fs.c in fs_overlayfs() function) the overlay home dir is empty, the overlay does not contain the original /home contents. I added code to create a second overlay for /home if the overlay home dir is empty and this seems to work. Not sure if a bind mount would work for /home as that might defeat the overlay. I also tried to add /home as a second lowerdir on the overlay mount, but that puts the user dirs at the / level which is not what we want. I can get code to you after I create a new cleaned up version.

[netblue30]

I'll look into it, thanks.

[dshmgh]

Should I clean up my code that seems to get around the issue and post it here?

[netblue30]

Yes, thanks!

[dshmgh]

OK This version is from 0.9.36. I compared to the latest on github and at first glance it does not look like the edits have any collisions. Does github really not allow .c files? The site complained until I added .txt. Also am using firejail with the palemoon browser (firefox fork). fs_0.9.36_new.c.txt

[Sidnioulz]

I'm going to state that dshmgh's code is likely infinitely cleaner to mines but I had to solve this issue too and decided to parse /proc/mounts on the system and apply rules to detect likely-persistent mount points (/mnt/..., /home*, /media/...) that require OverlayFS. I then place the odiff/owork folders differently from the original Firejail to make it easier for users to relate to where their data is likely to be.

Code is at https://github.com/Sidnioulz/firejail/commit/ecdae3a50bb089dd869995f3871522298914b7be and it IS dirty and it DOES NOT apply on any Firejail, my fork drifted too much and sadly I'm too busy to re-base and clean up

[Sidnioulz]

It also becomes trivial with the current --overlay feature to make OverlayFS systems with a private persistent home. I've done that in https://github.com/Sidnioulz/firejail/commit/ecdae3a50bb089dd869995f3871522298914b7be and with my current setup one can alternate between a private and "classic" OverlayFS home directory when they re-run a sandbox (I use sandbox names rather than PIDs for their .firejail folder).

[netblue30]

@dshmgh - Merged, thanks!

@Sidnioulz - I think there is more to come, I've just got https://github.com/netblue30/firejail/issues/361 and ended up mount-binding /run. Overlayfs doesn't play nice with tmpfs mount points also. At some point I'll have to start parsing the /proc/mounts.

[Sidnioulz]

@netblue30 yes, I may be wrong but if I remember properly I do a direct mount of /run/user/ since this hosts the DBus session and a few other things. I would not label my approach as secure though, only testing for usability and not for security at the moment.

On 10 March 2016 at 13:09, netblue30 notifications@github.com wrote:

@dshmgh https://github.com/dshmgh - Merged, thanks!

@Sidnioulz https://github.com/Sidnioulz - I think there is more to come, I've just got #361 https://github.com/netblue30/firejail/issues/361 and ended up mount-binding /run. Overlayfs doesn't play nice with tmpfs mount points also. At some point I'll have to start parsing the /proc/mounts.

— Reply to this email directly or view it on GitHub https://github.com/netblue30/firejail/issues/263#issuecomment-194834724.

Steve Dodier-Lazaro PhD Student University College London Free Software Developer

[netblue30]

In my case it started with a user complaining about PulseAudio socket in /run/user, but when I looked at /run it was missing all kind of other files. So I just did a mount-bind on /run - basically /run runs outside the overlay, and it fixed the problem for now.