Introduction to User-Mode Linux

developerWorks writes "Ever wish you had a place to let your Linux applications play -- where they wouldn't hurt anything else? Do your killer apps spend too much time killing each other? Originally conceived as a kernel developer's tool, UML lets you set up multiple virtual machines that are isolated from each other and from the hardware. Now, you can test applications all the way to failure without breaking the host system -- or even requiring a reboot. Veteran administrator Carla Schroder shows you how in this tutorial."

Comments

Re:Register?

[MBCook]

This isn't an article, it's a free online educational course. That's why they want you to register. It's still free. Why don't you try LOOKING at things before you start to complain?

Bye bye karma :(...

More on UML

[jsse]

The link requires (free)registration. It has a guide for Debian installation too. For Gentoo users, you may also look at gentoo's guide on User-Mode Linux.

Re:Register?

[jsse]

Well said! In fact, IBM DeveloperWorks has a lot of free tutorials like you can find this one in Linux tutorial.

It's one of the site worth giving your email address to. The biggest spam you'd get from them is just a (bi?)weekly IBM DeveloperWorks newsletter which you can easily unsubscribe.

I'm by no mean associate with IBM, in case you wonder. :)

Re:Better

[CableModemSniper]

Um, UML is User-Mode Linux not User-Mode BeOS. And it doesn't emulate the processor. It provides virtualized instances of the OS, not an entire emulated virtual machine. You want UML Ultra5, you have to be on an Ultra5 machine in the first place. Ditto for RS/6000 or any other architecture.

Re:Also VMWare

[LarryRiedel]

Not sure what advantages user-mode Linux would have over VMWare or Bochs.

It lets the kernel run as a regular user process, and has been developed to interact with the host in that context.

http://user-mode-linux.sourceforge.net/uses.html

Larry

Re:what am i missing here?

[aridhol]

Theoretically, yes. However, there's always the chance that something will break. You may trigger a bug in the kernel that allows breakage. Or you may be developing the kernel itself. You run it in user space, and you have to trigger multiple bugs to break the host - a bug in the UML system and a (hopefully) different bug in the host system.

Re:could this be...

[Anonymous Coward]

In a similar vein, could somebody tell me why we don't have a concept of ExecAs( "$username-nobody" ) yet?

DIY (or, already been done, depending on how you look at it). What you want is accomplished in unix using setuid bits (usually only for escalating privileges) or setuid(2) (always for reducing privileges). This is how su and sudo work - look at their perms, and you'll see that su and sudo are setuid root. Root processes can also call setuid directly, so sudo goes becomes root on exec and can go to any user from there.

1. Set your umask to 022 or 027.
2. Create a new user (ramses-nobody)
3. Put user in your default group
4. Run command as new user. Processes run as new user will have read-only access to your files.

   A number of ways to do this:

   1. sudo -u ramses-nobody evil-command
   2. If your system doesn't have sudo (a problem which you should correct), su to root and then su ramses-nobody evil-command
   3. If you can't be bothered to type a password whenever you do this and this a single-user system, write a small C program which execs evil-command and then set it setuid ramses-nobody (setuid bit on scripts is ignored in modern systems, so it needs to be a C program). Entirety of program: #include <unistd.h>
      
      int main(int argc, char **argv)
      {
      argv[0] = "/path/to/evil-command";
      execv(argv[0], argv);
      return 1;
      } Compile, set permissions appropriately. Or, if evil-command is a binary and not a script, just change ownership of evil-command to ramses-nobody and slap on setuid bit.

If this is a multi-user system, the only practical method is (1): you can set up sudo so that regular user ramses can run anything as restricted user ramses-nobody. You can even tell it to not prompt for a password when going from ramses to ramses-nobody. If it's a big system, you set up scripts so it becomes part of the account creation process. OTOH, if it's an big multiuser system, you don't worry about any of this since you keep daily backups :)