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.

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:

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.

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

enter root mode (sudo ...?)

launch standard install process

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

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

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

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.

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.

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.