You are viewing marnen

Marnen Laibow-Koser's Journal - Elementary OS VM installation [entries|archive|friends|userinfo]
Marnen Laibow-Koser

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Elementary OS VM installation [Mar. 19th, 2014|02:28 am]
Previous Entry Share Next Entry
[Tags|, ]
[Current Location |King Sauna, 321 Commercial Avenue, Palisades Park, NJ]
[Current Mood |curiouscurious]

Liveblogging my installation of Elementary OS. (Well, almost live: I'm editing as I go, but not posting till the process is complete.)

Note: Download times shouldn't be taken as gospel. I'm using the public Wi-Fi at King Sauna, and who knows how fast that is? Also, the act of blogging slows everything down a bit.

12:21 a.m.
Start downloading VirtualBox so I can create a VM.
Download done.
VirtualBox installed.
Click "New" in VirtualBox to create a guest image.
I picked Linux, but then it asked me what type? The logical choices seemed to be either Ubuntu (which Elementary is built on) or "Other Linux". No useful info on the Web, so I'll go with Ubuntu and see what happens. Also going with the recommended settings for RAM (512 MB) and virtual HD (8 GB, VDI format, dynamically allocated).
VM created. That was painless. Now, do I have to start it to install the OS from an ISO image? I'll check on this while downloading the ISO image.
Downloading what they describe as the 64-bit build of Luna. Uh oh, the file has "amd64" in its name. Will it work on my Intel Mac, or will I have to get the i386 build instead?
OK, apparently I can install an ISO image before starting the VM. I think I knew this at one point, but had forgotten it. :P
Insert newly downloaded ISO image into VM's virtual CD-ROM drive; start VM.
01 Booted
VM booted with no problem. Now to run the Luna installer.
Installed as follows:
  • 02 Install 1
    Checked the options to install updates and possibly proprietary Flash and MP3 players (neither was checked by default).
  • Allowed the installer to erase the entire virtual HD and partition it the way it wanted.
03 Crashed
WTF? The installer crashed.
A quick Web search suggests that this is not an unheard-of bug in the Ubuntu installer, but I haven't seen a solution yet. When I clicked to dismiss the crash messages, eventually I wound up in a live desktop session so I could diagnose the problem…
Performance in the live desktop session is so abysmal as to be unusable (I suspect that this is an artifact of VM performance, not of Elementary itself). Gonna reboot the VM and retry.
VM rebooted. This time, I'm going to run a live desktop session first, so I can make sure that things are working OK.
Looks good. Performance is incredibly snappy, and I was able to open Midori (the included browser, WebKit based) and load Web pages. Great. Retrying installation. If that doesn't work, I'll give the VM more RAM.
Hmm. As soon as I ran the installer app, performance went all to hell. Maybe there's a VirtualBox issue.
Same crash. Doubling VM RAM to 1 GB.
I guess that was the problem. Installer is now working.
Nice. There's even a "detect keyboard layout" tool that has you press some keys and answer questions about your keycap labels. (Of course, I have a boring US English keyboard…)
04 Installation progressThat's kind of annoying. I clicked the disclosure triangle during installation, but it doesn't look like the terminal-like window that shows up is actually expandable to the point where I can see what's going on.
Installation complete. I still have to add VirtualBox Guest Additions so I can make the Documents folder on my Mac visible to the VM.
On reboot, I had to virtually eject the virtual installation CD before Elementary would finish booting. :) Once that happened, boot and login proceeded flawlessly.
Shutting down VM so I can install Guest Additions.
Hmm, maybe I didn't have to shut down. So how do I install the additions?
The OS alerted me that I needed to update language support modules. Nice.
Following the instructions to install Guest Additions.
apt-get returned a surprising error: dpkg: error: dpkg status database is locked by another process. Retrying…
Worked on retry.
05 File managerNice file manager! Looks like the Finder and saves me from having to mess with mount points. But why isn't it in the Dock by default?
I had to run the Guest Additions installer with sudo. Not too hard to figure out, but I wish the instructions had said so.
Guest Additions installed.
Got my shared folder automatically mounting.
I need to add myself to the vboxsf group so I can read the shared folder. I'd like to do this without the command line, but there's no group manager in the System Settings application.
Ah, I found the User Accounts pane. I'm just not used to the way scrolling works here yet.
User Accounts doesn't do anything with group membership. Grrr.
I could do this from the command line, but it's a good excuse to look for other tools in Software Center. I like the Apple App Store-type interface, and I found an application called KUser that looked promising, but the reviews suggest it isn't worth it.
sudo usermod -a -G vboxsf marnen
But I still can't read that directory unless I'm root, even though I'm in the right group and permissions are rwxrwx---. Why not?
Apparently group membership is read at login. In 2014, why do we still have operating systems that work this way?
Logging out and in did the trick. Now, can I make a symlink to it in the file manager the way I can in the Finder with Cmd-Opt-drag?
Gah! Why is Files so poorly documented? And there's no OS help center the way even KDE had years ago?
Giving up and making the link from the command line.

OK, that's enough for basic OS and VM installation. Elementary looks good, but documentation is a little sketchy. At the same time, this is more usable and more attractive than any Linux I've so far worked with. We'll see how it performs over the next month.

At some point I should boot my Mac from an Elementary live CD to make sure it can see my Wi-Fi device…


[User Picture]From: blaisepascal
2014-03-19 05:43 pm (UTC)


"group membership is read at login" is not technically correct. For these purposes, it's effectively correct, but that's not fully what's going on.

Group membership of a process can only be changed by processes with CAP_SETGID privileges -- effectively root processes only. This prevents users from setting the groups of their own processes -- and thus potentially escalating their privileges and compromising system security.

So when you login, the login program validates your password, reads /etc/groups and /etc/passwd to find out about who you are, calls setgroups() and setreuid() to set your groups and user ids, then calls execv() to start your login shell. Gdm does something similar (it might even call login behind the scenes).

But when you update /etc/groups, existing processes cannot change what groups they belong to, and cannot access the updated privileges.

This plays both ways: "usermod -a -G vboxsf marnen" doesn't add vboxsf to your current shell's groups, but neither does the equivalent editing of /etc/groups to remove you from a group.

It's the way it is for security reasons, not because programmers are lazy. "Fixing it" would require redesigning, revetting, and redeploying a whole new security model for Unixoid systems.
[User Picture]From: marnen
2014-04-17 12:57 pm (UTC)


Sure, but when I run a command, why doesn't it check my group membership *at that time*, not simply at login? That appears to me to lessen security, not improve it: it lets me start new process with group settings that are now wrong.
[User Picture]From: blaisepascal
2014-04-17 02:06 pm (UTC)


Right now, /bin/login is the only program which reads and sets process group permissions based on /etc/groups. It runs as root (setuid root). Only root processes can set process group memberships. In addition, the kernel currently knows nothing special about /etc/groups, and the utilities running on top of the kernel are free to implement group permission schemes as necessary (such as /bin/login using a mysql database to hold user and group data instead of /etc/passwd and /etc/groups, or remote login tables, etc).

To change it so that group membership is checked when you run a command would require a lot of changes:

1. User processes are able to change their group memberships, rather than only root processes, or, alternatively, /bin/{sh,bash,zsh,csh,...} would have to run as root. Either way would basically trash security.

2. Or the kernel would have to check /etc/groups with every process creation, which would be both slow and would prevent the use of group registration other than /etc/groups. Sure, the kernel would quickly cache /etc/groups, but it would still slow everything down. Processes are quick and cheap in unixoid systems, so it's standard to spawn them as necessary to do stuff.

3. Or /bin/{sh,bash,csh,zsh,...} would have to be modified to bounce command execution through a special setuid root program whose sole purpose is to set up group permissions. Other applications which can run commands (like, say, /usr/bin/vim or /usr/bin/gcc) would either have to be modified to use this bounce command, modified to use a shell to run commands instead of running them directly, or keep the group permission semantics which currently exist (which would be inconsistent and surprising in its own right).

[User Picture]From: chocorua
2014-03-23 11:44 am (UTC)


The VirtualBox defaults are outdated - it's been several years since I first encountered a distro which wouldn't install with 1GB of RAM. Intel 64-bit processors implement both the AMD instructions and their own 'Itanium' instructions. I believe the latter are circling the drain in terms of adoption...