FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

sdolim · 2010-01-28 23:39:11

Dbus might be the culprit in the firefox issues.

Meaning: dbus is the likely candidate for the what needs the unix filesystem sockets which could be what are not working properly. Is it possible to start dbus inside the facade?

Last edited by sdolim (2010-01-28 23:42:24)

sdolim · 2010-01-28 23:50:09

@IgnorantGuru: that rings a bell:

$ mount | grep fuse
none on /sys/fs/fuse/connections type fusectl (rw)

@Xyne:

This is probably worth an advisory in your manpage to not dissociate things like /proc, /sys, and probably /dev.

Last edited by sdolim (2010-01-28 23:53:31)

Xyne · 2010-01-29 00:00:29

Thanks sdolim, I've added a line to the man page about that.

sdolim · 2010-01-29 00:04:36

This points out another use case for [link] in the config file:

- Ability to splice in a fake image of a directory tree (e.g. /dev, /etc/<something>, or /var) that contains stock, harmless entries. You would have created the skeleton for this somewhere else (e.g. $HOME/foo/var) beforehand. This allows software to run that expects a certain filesystem infrastructure to be there, without exposing your personal configuration or private data.

For this to work it might be necessary to add another section, [chown], to be able to spoof ownership of the redirected files (e.g. as root). (Or you could extend the chmod syntax: "root.root:-111".)

sdolim · 2010-01-29 00:21:28

Err... sorry for the endless stream of suggestions, but here's another one :-)

Change the config file format to be more like fstab -- A list of entries like:
/facade/path /real/path options

In the /facade/path, use either a single path or one of the glob: or regex: patterns.
In the '/real/path' column, use * to mean "same place", ! to mean dissociate, or some other path to link.
In the options use a comma-separated list of items like 'chmod=xxx' (or 'umask=xxx') to change permissions, 'uid=xxx' and 'gid=xxx' to change (apparent) ownership, 'live' to mean live, etc.

Keeps all configuration info regarding a single facade path in a single line.

Xyne · 2010-01-29 00:28:25

I'm glancing at the code now and I had actually implemented both of those before (although [link] was called [associate]). Some of the code is still there but it's commented out. I don't remember why I removed it.

I'll wait to uncomment/re-implement it until I can focus on the code. I just know that it would be a bad idea to try to fiddle with this without first fully re-immersing myself in the code, but I want to finish up may pacpan rewrite first and plug that into bauerbill.

You can try uncommenting lines 201-204 and adding an [associate] section to the config file to see if it works as expected. The config file syntax should be
<facadefs path> -> <real path>
The facadefs path should be relative to the facadefs root.

*edit*
I might change the config syntax, but I'm not sure that fstab syntax would work for all configurations, e.g. ones which don't specify two paths.

Last edited by Xyne (2010-01-29 00:30:55)

sdolim · 2010-01-29 00:50:42

Right, that's what the sigils '*' and '!' are for: when you don't have two paths.

Now that I think about it, it would make more sense to use a fixed sigil, like '-', in column 2 for all cases where there is no second path, and to use an option like 'unlink' in column 3 to signify dissociation (since there are probably not going to be any other options then).

Example (entries taken from your manpage):

glob:/home/* - chmod=-222
/usr/sbin - unlink
glob:/tmp/* - live

Examples with linking:

/home/fakeuser /etc/skel uid=200,gid=200,chmod=-222
/var /home/me/myfakevar uid=0,gid=0,chmod=-022
/etc/sudoers /home/me/myfakesudo uid=0,gid=0,chmod=-226

Last edited by sdolim (2010-01-29 04:44:54)

IgnorantGuru · 2010-01-29 01:13:24

Interestingly, I ended up getting that same firefox error while trying to run firefox in a chroot jail. No aufs or fuse involved - I just bind mounted some directories. The solution in this case was to bind mount /tmp into the chroot - no more error. So whatever firefox needs seems to be there.

Here's all firefox seemed to require (probably less)
bin etc lib lib64 sbin tmp usr var/lib home/myuser/.mozilla

sdolim · 2010-01-29 01:27:37

/tmp is where the unix sockets usually live, so that points suspicion back in the direction of dbus or something like it.

IgnorantGuru · 2010-01-29 01:27:44

I have narrowed the firefox error down to the /tmp/orbit-myuser folder, which is user-owned and empty before firefox runs. If I create an empty folder of that name in the chroot jail, with the same permissions, firefox still gives the error and creates a new orbit folder with numbers at the end of the name. So somehow it knows that isn't the 'real' orbit folder. Yet if I bind mount /tmp/orbit-myuser onto /mnt/chroot/tmp/orbit-myuser, then firefox doesn't give an error. There is a socket in the folder while firefox is running.

"ORBit2 is a CORBA 2.4-compliant Object Request Broker (ORB) featuring mature C and Perl bindings."
???

EDIT: Also, I got the save-as dialogs not working on my chroot firefox. It turned out what was causing it was that the last used folder for a save did not exist in the chroot. Strange that it wouldn't just revert the home folder or something. Doesn't appear to be related to /sys afterall, at least in this case.

Last edited by IgnorantGuru (2010-01-29 01:47:50)

sdolim · 2010-01-29 01:50:22

I think that is how firefox talks to the bonobo server, in order to support plugins.

sdolim · 2010-01-31 03:39:37

On the subject of breaking out of a chroot jail, you may be able to prevent that with facadefs.

According to chroot(2), a root-privileged process breaks out of the chroot jail by doing this:
mkdir foo
chroot foo
cd .. # repeat this until reaching the real /
It takes advantage of the fact that chroot is not reentrant.

But a defining feature of / is that it's .. points to itself. You can likely reproduce this behavior in facadefs by substituting any resolved path that points outside of the chroot jail with the jail root itself. Perhaps a 'chroot' option in the config file could be used to say that a particular path acts this way. Any process chrooted inside of that path will be unable to escape via the above method.

Arch Linux

#26 2010-01-28 23:39:11

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#27 2010-01-28 23:50:09

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#28 2010-01-29 00:00:29

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#29 2010-01-29 00:04:36

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#30 2010-01-29 00:21:28

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#31 2010-01-29 00:28:25

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#32 2010-01-29 00:50:42

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#33 2010-01-29 01:13:24

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#34 2010-01-29 01:27:37

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#35 2010-01-29 01:27:44

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#36 2010-01-29 01:50:22

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

#37 2010-01-31 03:39:37

Re: FacadeFS: A FUSE-based filesystem sandbox. [TESTERS NEEDED]

Board footer