bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hiding nodes with unionmount


From: Arne Babenhauserheide
Subject: Re: Hiding nodes with unionmount
Date: Thu, 30 Jul 2009 21:26:11 +0200
User-agent: KMail/1.12.0 (Linux/2.6.30-hh2; KDE/4.2.98; x86_64; ; )

Hi scolobb, 

Am Donnerstag, 30. Juli 2009 14:37:39 schrieb Sergiu Ivanov:
> > $ 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).

I assume to make it really clean it would have to be something like 

$ ln / chroot/real_root
$ chroot chroot /bin/bash
$ settrans -a / mine real_root

Or at least something like it (I'm not firm on the exact way to do it). 

@Olaf: How would you go about that? 
Is it possible to just unionmount / on another node and then chroot to it? 

And what does a subhurd do exactly? 

(I'd also be glad to just get a pointer :) ). 

The goal is to have / with some modifications. The "mine" translator is a 
theoretical translator which turns the system into my private system - though 
only for me :) 

It should be able to modify the system and save all changes I do to the system 
in a personal file - and only there. 

That would even allow me to do a "rm -rf /" which would naturally make the 
system unusable for me (my / would be empty), but wouldn't affect anyone else. 
My personal environment would then simply contain a notice for the filterfs 
that it should filter out all files :) 

> > 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 :-) 

That would just enable us to effectively mount a set of patches ;) 

We could then check which file we removed, and if the underlying filesystem 
changed, we'd be able to see the diffs and "merge" the changes with our 
changes. 

But it can simply be replaced with a package manager which knows which 
packages are installed in root and which files they own. 

The filter needs to know what to hide, and I though a version tracking system 
could provide that information. But the package manager can do it, too, and 
with far less overhead. Portage already has all information for that. 

> 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?

No, that's exactly what I meant. 

> So, your personal setup also includes the modified files from some
> system directories, right?  (like /var/db, /etc/)

Jupp. 

Ideally it would also be able to modify /dev /proc and anything else, so 
programs see exactly what I want them to see. 

A firewall could for example be a translator on the network device, so it 
would automatically be completely transparent, and an audio equalizer could be 
a translator on /dev/dsp

> > 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.

It is what I see as one of the main "selling points" of the Hurd, though I'm 
not yet perfectly firm on the technical side. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]