[feature-request] Easier Installer for Linux host (for single-user systems)

[Technologov]

This software is used heavily for one-user Home machines, and therefore I recommend a series of steps that will optimize user-experience on single-user Linux systems, eliminate the need for adding that single user on a home machine to a "vboxusers" group. The end result will be easier installation process on Linux host (for single-user systems), without hurting security in any way.

Multi-user host systems will setup and work the same as today.

The new setup must be run from normal-user (non-root), so you get instantly added to the right group, permission are set for you, and the rest of setup will proceed as root.

Concept taken from klik client at: ​http://klik.atekon.de/client/install

You can run this client to understand how this works (on a guest Linux VM) - it's a setup that starts from normal user mode and then jumps into root mode in the middle to complete tasks. When jumping to root mode, it asks for root password (in the middle of setup).

Tasks:

1. give warning when setup launched as root that it's not recommended for single-user systems, that only multi-user systems need to start setup from root.

2. remember current user somehere (in /tmp ? or bash variable ?)

3. enter root mode (sudo ...?)

4. launch standard install process

5. add current user (from /tmp ? or bash variable ?) to that group and set other (usb ?) priviledges

This is just a concept - what do you think of it?

I might try to write a bash script that does this, but I'm noob in this stuff. (so would be glad to see some Pro doing this)

=============================

This might be a small step, but a really confusing one for newbies. My VirtualBox refused to work and I had patience to tinker around and dig, I spent valueble time and want to prevent other from this, I prefer user-friendly concept of "just-works".

-Alexey Eremenko

[Achim Hasenmueller]

We have improved the instructions in 1.3.4 and also now check for the right permissions when starting VirtualBox.

Your approach isn't really much better IMHO. On many systems sudo is either not present or the current user isn't configured to be allowed to use it.

[Technologov]

On what distros sudo doesn't work?

AFAIK, "sudo" works on all distros. (klik-client is also a multi-distro installer package, and is known to work on *lots* of distros.)

[Michael Thayer]

Alexey, I have a problem with your suggestion as it stands - in my view a user should never have to input their password into an untrusted application. Obviously I trust our installer, but I would not want a user who has not looked at the source to trust it. Therefore it should be invoked as "sudo VirtualBox.run install" or similar.

If it is invoked with sudo, then the environment variable SUDO_USER will contain the user name we are interested in, which effectively solves the problem in this case. The "or similar" bit is the rub. We should probably check how the most popular alternatives behave (mainly synaptic with gtk-sudo - which probably also sets SUDO_USER - and adept installer with kdesu - no idea about that one. Feel free to add other cases which might be important).

The other problem which must be addressed here is that Linux takes a while to notice that a user has been added to a group - usually requiring at least a logout and another login. I still haven't quite worked out why - do you have any idea how to get Linux to notice the change?

I will not get around to implementing this immediately - I will probably do it next time I am working on the installer, so no timeframe. You could accelerate the process and help me greatly if you can answer some of the questions above, since the actual code added will be reasonably trivial. Changing the installer is quite a time investment though, since it has to be tested on as many systems as possible. Any change usually breaks at least one supported setup.

[Michael Thayer]

OK, admittedly once they have run it with root privileges it is trusted anyway, so ignore that point. But I still prefer to rely on sudo and friends for managing passwords.

[Technologov]

michael:

Please look at the "klik-client" (bash script) which features a cross-distro installer based on the technology I described above. (and it is known to work on RedHat/SUSE/Debian/Ubuntu and a lot of others...)

You can find it here:

klik.atekon.de

I'm not a developer, but I know that it detects if you're running GNOME, KDE, or command-line, and gives GNOME SUDO, KDE sudo, or command-line sudo accordingly.

I do not know any way that allows you to actually accelerate a Linux to understand new user-permissions, *but* the klik-client installer has a technology that allows displaying of dialog mesages (again auto detecting GNOME/KDE/command-line).

Recommendation:

So at the end of install, we could display a message box saying: "Install completed succesfully! WARNING: To use it, please logout or reboot first."

This is known to work simply great. So please look at the source-code (bash script actually).

-Alexey Eremenko

[Michael Thayer]

Just checked: su, sudo, kdesu and gksudo all leave the environment variable USERNAME set to the currently logged in user (the user who invoked su, sudo or whatever). The last three also set SUDO_USER, but USERNAME seems good enough. Would it solve this for you if we added that user to the vboxusers group during installation? Of course, I will take a look at the script you pointed me to, but it sounds like that approach would involve bigger (that is, more expensive in testing time) modifications to the installer, something which I would rather avoid if possible. And of course, I have to test on loads of different setups anyway, so I will notice if it does not work somewhere :)

[Technologov]

AFAIK: You don't have to really restart your Linux system after VBox setup; besides, this is bad Linux practise.

I think, that instead of restarting we need:

1) insmod vbox.drv (insert Vbox LKM)

2) logout current user (ask user first?)

3) login current user

What do you think?

-Alexey

[Michael Thayer]

I would definitely not log the current user (let alone restart the system) from the install script. If I were sure that logging out is enough, I would be happy to tell the user to log out and in again after the installation.

[Technologov]

michael wrote:

Alexey, I have a problem with your suggestion as it stands - in my view a user should never have to input their password into an untrusted application.

my opinion:

Security-wise, there is no difference between starting VBox installer as normal user, then input the root password, or manually enter root mode, then installing this software. The risk user takes is equal.

This idea only applies to the "All Linux Distro" package, not to RPM/DEB.

-Technologov

[Michael Thayer]

Regarding your last point, see comment 4. I don't think that this feature is worth implementing if it will only apply to the shell script installer, as that is more a special case these days; more generally, user interaction inside an installer is (in my current opinion at least) something that should be avoided. I also don't know a good generic way of adding a user to a group using a shell script, particularly given that there are a number of different cases that need to be handled - just as one example we should at least detect if the user is using NIS login, as we won't be able to add them to the group in this case.