Hi!

Don't know if this is expected or what. My Ubuntu 12.04 laptop won't shut down if besides me (administrator), there is another user on the machine that is not logged off. When I do the shut down sequence, it returns me to logon as if did a restart. To shut down, the other user has to logoff. Please, advice.

Linux is a multi user system. There are deployments with hundreds of users at one time. Obviously you can't have one of them shutting the system down.

The queation here is who is the other user. Ubuntu uses sudo by default for gaining root permissions. This means that if you are using sudo for your commands that require root (another user; the one that actually creates your account) permissions you should not have this problem.

The same should also be true if you use the "sudo su" command to get a root prompt (#) and then exit the terminal.

If you, however, have enabled an actual root acount, as most Linux distros do, and then use the terminal as root you have loged in as root and therefore there is another user loged in and thus you get that message. Giving that users password when prompted will allow you to shut down.

I have no idea what you have done to the piss pour security system under Ubuntu, if any, or what sort of bugs are present in that system but it would be helpful to know how you use the system for processes that require root permissions. These include anything that makes basic systemic changes to your system; installing or removing packages, editing system files (not the ~./foo files in your /home/<user name> directory that are user land config files for your specific user), removing system files or adding system files.

widget:
There's no argument that Linux is multi-user. But I'm talking of a single laptop that has various users created on it, where I have administrative privileges and the others don't. This machine is not doing what it is supposed to be doing when the administrator shuts down the pc: warn me that there are other users logged-in and that they may loose data if you shut down. Don't know why you bring up a discussion about the root account. I never enable the root account on my machines; sudo satisfies my needs.

Regardless, I came here to look for advise from the experts, for a legitimate problem that I have on my machine, but instead, I get criticism on imaginary actions that I perpetrated in my machine to screw the system security. I assume that the mission of a forum like this one is to help people less knowledgeable (like me), and answer their questions (including the stupid ones) with courtesy and deference. Am I correct?

You are absolutely right that we are here to help. We are also not mind readers. We have no idea what you have done to your system and can't unless you tell us. Sorry about that.

If you only install with one normal user, whether or not you create a root account, you will have a multi user system. Root is a user on all Linux systems. You can check this by looking at your system files and noting the /root. This is the home directory for that user. There should not be anything in the way of user land sub directories there but there will be, or should be, some ./foo files there, at least one for bash.

Yes your system should tell you that.

The best advice I can give you is to file a bug on it. You need a Launchpad account to do this.

Good luck with that. This is not something that Canonical can wait for upstream to fix as it works upstream.

This sounds like a very likely result of the very sucessful effort on the part of Canonical to have an insecure system. You can see this quite easily by booting to recovery mode. You will then be presented a root prompt (#). No other distro does anything this silly except for ones that use one of the Canonical Ubuntu or other family members as the base for their respin.

If you are running a system with more than on "normal" user on it I would guess that you wish to become familiar with GNU/Linux. If this is indeed the case then I would suggest trying a distro that doesn't assume you are too stupid to learn to use GNU/Linux as it is set up, by the kernel to be run. If you want something up to the cutting edge try something like Fedora or perhaps, I am not sure about this never having used it, openSuse.

You are more likely to have fewer problems if you use something not quite as cutting edge like Debian Stable or CentOS.

All systems offer the use of sudo. They also have it configured the same way yours is and leave it to the administrator to configure it properly for what it is intended to do. That is not to give any user, using their user password, permission to do anything they want to the system. It is so that you can give specific users limited permissions.

In a business you may want one user to be able to create user accounts but not any other privileges above what a user normally has. You may want another user to be able to add packages to the system but not remove any. And so on.

The only user that should have complete control is root.

The default configuration of sudo is very handy when you install a system. If you forget to give root a password (some installers avoid this by simply stalling if you don't do this) but in any case the installer may not set it up correctly. In that case the person installing the system will notice this lack when they, sensibly, check to see if the root password works. If not they can use sudo, as configured, to create that password.

When that is working they can then configure the /etc/sudoers file to meet the needs of the system and the users that use it.

Having any user that is just poking around do something like delete partitions is probably not considered a good setup.

Between the sudoers file configuration, group permissions and group membership of individual users you can have a very secure system where only root can do all jobs and access all files and perform all actions.

This means that if someone, for instance, phishes one of the users passwords they are limited, even then, in the damage they can cause to the system because that user doen't have the power to do everything.

Bugs filed with Launchpad, particularly dealing with things of this nature are very slow to be fixed and will be ignored unless there is someone else filing on the same problem. When you go to Launchpad and start a bug report you are given the chance to search for similar bugs. Do that. Hopefully you will find one but most Ubuntu users will not bother or care about something like this so I doubt it. If you do it may be old. And probably has not been verified.

Therefore do not file a new bug. There is, on the page for the existing bug an option to add your "me too". If I remember correctly it is worded something like "This affects me too". You then have the chance to go to the bottom of the page and leave a comment.

Discribe, in detail (they are not mind readers either), the conditions under which this occures. Then hit the button to file the the stuff.

One thing to mention, which we have no idea about yet, is if this occures all the time or only after you have used the sudo command in cli or given your sudo password for some gui application like synaptic, gparted, etc.

Also if this occures when you have auto login enabled or if it occures when you are loging in normally.

Another thing you should probably check before filing a bug is to find out if this happens using a different DM. I woudld think the gdm3 or what ever the current version is would be the easiest to switch to from Lightdm as it is the default for Gnome as the Gnome project puts the Gnome system out. There are others and you may want to try something like slim or xdm which are old and pretty simple and therefore pretty reliable.

You would need to purge the lightdm package and install what ever you want to try.

Would be better to reboot (from the cli) without a dm installed and log in at the tty prompt using the command startx (as long as you only have one desktop environment installed - startx will start the default DE but not others - any others require a modified start command). Use the system as usual and then shut it down or reboot and see if you get the same behavior there.

This way you can file a bug that give them something to go on. Also if it is simply a lightdm problem you can know that is the package to file the bug on instead of using the catchall of filing against the system which is, if I remember correctly, is done by putting "ubuntu" in the package box.

There are also the logs for booting in /var/log and I would definitely be looking at /var/log/lightdm.

Have you checked ~./xsession-errors? Kind of a long shot but might be something in there to give a clue.