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

Re: Installing debs in ~user/ or /usr/local?



On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote:
> I'm beginning to think a better solution would be an operating
> system within an operating system, and let the user play in her `own'
> system, and while it for all intents and purposes seems to be running on bare
> metal, it really is a virtual machine. That would be quite fantastic for doing
> normally privileged operations without a security risk, though.

In the Hurd, any user can boot a sub-Hurd system off a root filesystem
image. (root means root filesystem, has nothing to do with the user root).

In this sub-Hurd, it appears that the user has indeed control over a new
instance of the Hurd operating system.  The root filesystem can contain
different software than the "default" system.  From the default system, the
processes run under the id of the user, but within the sub-Hurd, the user
can acquire super-user privileges (uid 0).  No permissions leak outside the
sub Hurd.

sub-Hurds can be nested of course.

There is currently no virtualization implemented: All direct kernel accesses
(hardware access etc) are simply forwarded to the systems kernel. However,
the kernel is used for few things: As a microkernel based system, most of
the functionality lives in user space kernels (which are duplicated in the
sub Hurd).

However, the boot process (the command used to boot the sub-Hurd) can
intervene such kernel calls and virtualize them.  This is something that
interested people can work on.  Indeed, you can implement whatever
functionality you want.  Again, systems security is strictly preserved by
the default servers (modulo bugs ;).

> For that to work, you'd also need to set up a base system for each and
> every developer. That would waste a lot of disk space in a hurry. Perhaps
> copy-on-write file links would do the trick here, allowing root to keep a central
> repository of a prototypical base system, and allowing each developer to change it at
> will,

For the Hurd we plan something called "shadowfs".  shadowfs will allow to
stack filesystems in a single view.  For example, you could join a read-only
ext2fs filesystem and a tmpfs (in RAM) over it.  Files in the tmpfs would
shade the underlying ext2fs files, and new files would be created in the
tmpfs, too.  This way you get the "copy-on-write" trick you imagined.

But that's not all.  Ideally, such a shadowfs implementation would merge
multiple filesystem trees, for example the system tree (ro) plus a user
provided "root" filesystem.  Then you can use this shadowfs to boot a
sub-Hurd from, running from the default system usually but running from your
files where they exist.  This way you can test new servers in the sub Hurd
with minimal cost.  Oh, did I mention that all sub Hurd processes appear in
the parents sub Hurd process table? This way you can attach gdb to them
(from the outside) and debug them like any other process (even
"system-critical" servers).  Of course, if the sub Hurd crashes, the parent
systems are not affected.

> but without wasting disk space unless something actually changes. Of course,
> that means big changes in the kernel's VFS code and possibly elsewhere, but
> copy-on-write links would be way cool for other reasons as well[1-2].

In Linux, yes.  This would be close to impossible to implement securely
without rewriting major parts of the kernel (possibly all).  The Hurd
provides the substantial features and design paradigms today (there are
bugs, and there are missing features like full virtualization and shadowfs,
but booting a sub Hurd for example works).

> [3] I understand Microsoft has done something like that in one of their
> operating systems or another. It was on Slashdot a while back. Most people
> said that what they `invented' are really just symlinks, but the major
> difference is that they're copy-on-write, whereas writing to a symlink
> on Unix will write to the file pointed to, but overwriting a symlink will
> overwrite the symlink, not the file pointed to this; is a
> pseudo-copy-on-write behavior, but not real copy-on-write like what MS
> did. Of course, they attached some lame marketroid buzzword TLA to it,
> but `copy-on-write link' works for me. ;)

If you want such a thing, you can implement this as a Hurd filesystem server
and run it as a user. You don't need to recompile, install and boot a new
kernel.  You just attach your server to some directory ("mount" if you
want), and go.  You'd probably violate some POSIX requirements with such a
thing, but you don't need to limit yourself to it.  The Hurd is a POSIX
system in its default configuration, but the idea of the Hurd is that any
user can extend the system in such ways you describe (and others) without
asking anyone.

For the far future, giving shadowfs, I'd be interested in a simple packaging
system which allows to install multiple version of a single package, and
which allows users to install packages.  Basically, users packages would be
mirrored over the root filesystem with shadowfs, and a sub Hurd booted.
This way every user can have the filesystem look like he/she wants.

Thanks,
Marcus

PS: Probably move this to debian-hurd if you have further questions.

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



Reply to: