System settings not prompting for password

[flipflip47]

Hello everyone,

I notice that some things in system settings do not ask for password when making changes. For example, when i make changes to the screen locker or power management there is password prompt. I understand that the more critical settings you do have to enter a password to make the changes. My question, how do I control which changes asks for passwords in system settings? Thank you for taking the time to read, and possibly helping me with, this.

[whatthefunk]

You can do that by editing the /etc/sudoers file.
https://help.ubuntu.com/community/Sudoers

Be careful doing this: making mistakes in your sudoers file is a great way to screw up your system. Also, its is not recommended to take away password usage as this could lead to system vulnerabilities. Before doing anything, make a backup of /etc/sudoers and read up. Dont forget that when editing sudoers, you need to use visudo instead of a more general editor.

[flipflip47]

Thank you whatthefunk for the info. I do not want to remove passwords restrictions, I want system settings to prompt me for changes I make using that applet. If I want system settings to prompt me for a password everytime I change screenlocker, for example, is this the way to go about it?

[SteveRiley]

There is no reason to prompt for a password when changing the screen locker, because each user on the system can have his/her own locker configured.

Password prompts are reserved for actions that affect the entire system. For actions that affect only your own user account, no additional password prompt is required beyond the one you typed when you logged into your account. This is by design.

[flipflip47]

I undertsand that this is by design. The initial question still remains, if I wanted to would editing sudoers be the way to do it?

[SteveRiley]

No, and there's no reason to.

Think about it like this. Entering a password is required whenever you need to cross a security boundary. You have to enter a password to log into your own account -- this is the per-user security boundary that you must cross so that you can do per-user things. Per-user things include creating files, listening to music, watching movies, surfing the web, reading email, and chaning per-user account settings. You have already authenticated yourself to the machine during log on. It is unnecessary to re-authenticate just because you want to change a user-level setting like wallpaper or the screen locker.

You have to cross another security boundary to make changes that will affect all users on the system or the actual system itself. Because standard user accounts lack the privileges to make these changes, an account with elevated privileges is required. Typically, these accounts obtain the necessary privileges by being a member of the adm, admin, sudo, or wheel groups. However, it's unwise to routinely operate on a day-to-day basis with these accounts, so Linux-based systems are structured such that you elevate only when necessary. To obtain the privileges on a temporary basis, you must invoke the sudo (for text-based programs) or kdesudo (for GUI programs) command. You also have to specify the name of an account in one of the high privilege groups, and supply its password.

On a standard *buntu install, the first user account is automatically added to the sudo group. But, like I mentioned, a normal log in doesn't grant elevated privileges. You need to invoke sudo or kdesudo. You can omit your user account name, but you still have to supply the password, because you are actually changing the set of privileges assigned to the account's authentication token.

[flipflip47]

Ok, so I understand that to you and many others would seem it unnecessary to do so. Moving past whether it is necessary or not, how would I go about doing such a thing?

[SteveRiley]

There is no mechanism to do what you're asking. It's equivalent to preventing you from manipulating your own files without asking for a password, because the only thing that the screen locker utility (and similar ones) does is manipulate configuration files in your own home directory. You already have full access to these files from the console window and Dolphin, and you already provided your password when you logged in. The GUI tools simply offer an alternative to manually editing the files.

Can you tell us more about why you wish to do this? I get the sense that you're trying to accomplish something other than protect you from yourself. If we understand your requirements better, we can possibly offer a solution that works within the Linux and FSH (file system hierarchy) security model.

[flipflip47]

I dont have any specific requirements, just wanted to play around with the system. I am trying to make it so that any change I make the system, via system settings, asks me for a password. I guess it is no big deal if it cannot be done. I just wanted to be able to leave my pc when friends and family are over, or when I allow them to use it, without worrying about changes being made. I know I could always lock it, but if i ever just forget, a password would be needed for any change. I obviously would not lock it if I let them use it. Since i am the only user on this pc, there is no worries about other user accounts. I understand if it cannot be done, or just something too difficult to accomplish. I just wanted to know how its done. I am really happy with linux and when i get an idea about something to do on it, I want to know if it is possible and how. Is it easier to password protect system settings? Please believe me when I tell you that I know it is not practical, but that is what I want to accomplish. If password protecting system settings itself is easier, please point me in the right direction.

[HalationEffect]

Why not just create an additional 'guest' user account for visitors to use? Don't give the guest account sufficient privileges to alter system-wide settings, and if anyone tinkers with the user-specific settings, it's no biggie because it will only affect that account.

[flipflip47]

The reason is because that does not accomplish what I want to do.

[SteveRiley]

I'll answer in parts.

Is it easier to password protect system settings? Please believe me when I tell you that I know it is not practical, but that is what I want to accomplish. If password protecting system settings itself is easier, please point me in the right direction.

It is not possible to do what you want. As I wrote earlier, the various graphical controls in the system settings are nothing more than alternative ways of changing information in text-based configuration files. Because these files belong to your user account, and because the system allows you to freely edit them in a text editor, the system also allows you to freely change them with graphical controls.

I just wanted to be able to leave my pc when friends and family are over, or when I allow them to use it, without worrying about changes being made.

Thank you! Now we understand your requirement. Usually it much better to seek solutions by stating the requirements, rather than trying to guess at a potential technical approach. HalationEffect's answer is what I would recommend. Create a standard account -- call it "Guest" -- and allow people to use that. This account, because it's a standard account, has no system-wide privileges. You can even configure it without a password. You shoud, however, have a password on your account. When people visit your house, log out of your account and log into the guest account. Now, your visitors can surf the Internet and do other things. They can't change system settings, and they can't change your settings. When your visitors depart, log out of the guest and log back into your account.

I know I could always lock it, but if i ever just forget, a password would be needed for any change.

If you're worried about forgetting your own password, write it down. Don't label it -- just write the password down by itself. Now, protect the piece of paper. Put it in the bottom of your sock drawer or something, in a different room than your PC.

I am really happy with linux and when i get an idea about something to do on it, I want to know if it is possible and how.

This is good, we want you to be happy. We're here to help.

[HalationEffect]

The reason is because that does not accomplish what I want to do.

Colour me confused then, because what you said you wanted to do was prevent visitors from changing either system-wide settings, or your user account's settings. I assure you that my suggestion absolutely would achieve those goals.

Is there some other, additional goal you want to achieve, but haven't stated? If you have unstated requirements, it's unlikely that anyone is going to be able to offer a satisfactory solution.

Unfortunately, there is no method of preventing anyone logged in as user "X" from changing settings that belong to that user. Imagine having to enter a password before being able to edit a text file in your home directory that you created in the first place. Nonsensical, right? And there lies the problem. All user settings are stored in text files that belong to that user, and the System Settings GUI is just a fancy way of viewing and editing those files. As far as the Operating System is concerned, the user doesn't need to give a password to alter his own user settings, because he already gave his password in advance - when he logged in.

(Edit) Even if you hunted down all your user settings files and changed their ownership to the root account, I still don't think it would achieve what you appear to want (the System Settings GUI asking for a password before allowing a user to edit his own files). Yes, those files would now need privilege escalation (i.e. entering a password) to view or edit them, but the System Settings GUI expects them to be owned by the currently logged-in user. It doesn't expect to ever have to ask for a password to view or change user settings, therefore it would make no sense for it to be programmed to do so. I expect it would just throw an error instead.

[SteveRiley]

(Edit) Even if you hunted down all your user settings files and changed their ownership to the root account, I still don't think it would achieve what you appear to want (the System Settings GUI asking for a password before allowing a user to edit his own files). Yes, those files would now need privilege escalation (i.e. entering a password) to view or edit them, but the System Settings GUI expects them to be owned by the currently logged-in user. It doesn't expect to ever have to ask for a password to view or change user settings, therefore it would make no sense for it to be programmed to do so. I expect it would just throw an error instead.

It would also break a lot of applications. For example, the Personal Settings module draws from Akonadi. If you changed the owner of your Akonadi resources to root, then you'd have to run Akonadi as root -- and, by extension, run KMail, KOrganizer, and KAddressBook as root, too.

---

@flipflip47: HalationEffect and I have explained the situation in nearly identical terms. Remember earlier when I asked for a higher-level explanation of your requirements, so that we could offer a solution that works within the Linux and FSH (file system hierarchy) security model? Based on what you've told us now, a separate guest account is the correct solution.

[flipflip47]

Colour me confused then, because what you said you wanted to do was prevent visitors from changing either system-wide settings, or your user account's settings. I assure you that my suggestion absolutely would achieve those goals.

Is there some other, additional goal you want to achieve, but haven't stated? If you have unstated requirements, it's unlikely that anyone is going to be able to offer a satisfactory solution.

Unfortunately, there is no method of preventing anyone logged in as user "X" from changing settings that belong to that user. Imagine having to enter a password before being able to edit a text file in your home directory that you created in the first place. Nonsensical, right? And there lies the problem. All user settings are stored in text files that belong to that user, and the System Settings GUI is just a fancy way of viewing and editing those files. As far as the Operating System is concerned, the user doesn't need to give a password to alter his own user settings, because he already gave his password in advance - when he logged in.

(Edit) Even if you hunted down all your user settings files and changed their ownership to the root account, I still don't think it would achieve what you appear to want (the System Settings GUI asking for a password before allowing a user to edit his own files). Yes, those files would now need privilege escalation (i.e. entering a password) to view or edit them, but the System Settings GUI expects them to be owned by the currently logged-in user. It doesn't expect to ever have to ask for a password to view or change user settings, therefore it would make no sense for it to be programmed to do so. I expect it would just throw an error instead.

The problem is not if it is nonsensical, the problem is that I want to know how it can be accomplished. Like I said before, I am aware that it may not make sense to you, but that is what I am trying to accomplish. I, for one, do not care that I would have to enter a password again if I want to change my screensaver or screenlocker settings. Or if i have to enter password again to change the background on my desktop. You seem to getting into it does not make sense to do it, rather than finding a way to do it. Having said that, I realize you said you do not know, or it cannot be done. For me, you have answered the question to the best of your ability and I thank you for that.


Now Steve, when i mentioned that if i forgot, i did not mean if i forgot my password, rather if i forgot to lock my screen when i got up. I will wait and see if anyone else chimes in before I mark it solved. I thank you both for a very healthy discussion on my issue. Who knows, I might make another kde system and see if I can accomplish what I want to do. I do not want to break anything on this system. Thanks again guys.