Re: Hiding nodes with unionmount

[Sergiu Ivanov]

Hello,

On Thu, Jul 30, 2009 at 11:12:03AM +0200, Arne Babenhauserheide wrote:
> Am Donnerstag, 30. Juli 2009 10:48:00 schrieb Carl Fredrik Hammar:
> > A cleaner solution would be to first mount a hypothetical ``filterfs''
> > that removes the files, and then do a unionmount on top of that.  Also you
> > could just simply set a lib.so.1 -> lib.so.3 symlink in the mountee, which
> > would shadow the underlying lib.so.1.
> 
> That's definitely sounds cleaner. 
> 
> Could a filterfs and unionmount be combined to a fully transparent writeable 
> filesystem which uses a readonly filesystem as base? 
>
> That way I could use a LiveCD as base and store my changes on a USB-stick. To 
> setup my environment (including my user data) I'd just set my "this is my 
> system" translator on root. 
> 
> $ settrans -a / mine /mnt/usb/arne.tbz

You mean union-mounting ``mine'' here, right?  Note that you still
require root privileges to set a translator on / .  (At least I'm not
allowed to do that in my instance of the Hurd).

When I tried to set a translator on / as root, I didn't really succeed
either, but this could be because I was doing something wrong.  I did
the following:

 # settrans -a / <trans>

I can see no difference between the output of ls / before mounting
<trans> and after it, although I can see the translator process
running.  Also, I can settrans -gf / , and it kills <trans>, and I
still can ls / quite successfully.  However, whenever I do fsysopts /,
I never see anything but the expected ext2fs.static translator.

> Other users would still see the original system, but I'd work in my
> own environment.

I'm not sure it is really possible, since you are setting a translator
on / .
 
> It could even use a version tracking backend, which tells it which files need 
> to be filtered and added. That way a change in the base system could be 
> reflected in the filterfs. This would then use a lot more space, but if the 
> main repository would be used as a base by all users, that space would only 
> be 
> required once. 

I'm sorry, but I cannot see why you need a version tracking back-end
in this case.  Actually, what I cannot fully understand is the
``version tracking'' part :-) If your point is that filterfs should
show only *a part* of the base filesystem, then you don't really need
any version tracking.  Just tell the all-mighty filterfs to mask away
the corresponding files.  Do I understand something wrong?
 
> Instead of that it could also just access an installed package database for 
> filtering installed programs - in Gentoo that would just mean accessing the 
> files inside /var/db and telling the filterfs (or a preprocessor) not only to 
> mask files but to mask installed packages so they can get replaced completely 
> by the users installed packages. 

So, your personal setup also includes the modified files from some
system directories, right?  (like /var/db, /etc/)
 
> I could have a Gentoo where every user can modify the whole system without 
> affecting any other user. 

This sounds cool :-) And also very much like sub-hurds, actually ;-) I
don't know whether sub-hurds must always use a chrooted environment,
but, even if not, working within one and doing a chroot explicitly
gives you a personal world per user, too.

Regards,
scolobb