Basically the sudoers file is used to specify who is allowed to run sudo and how. So you can specify here what commands can be executed by which user (see man visudo for example)
su (not sudo) requires to know the password of root, so you only need to change that password and noone will be able to use it.


# is a comment sign, it means the chars in that line (after #) are ignored. It is almost same as completely removing that line, the only difference is you can easily restore it by removing that # (which cannot be done if you deleted it).

No, it can not. You need policykit, or consolekit ( not maintained any more ), or consolekit2 ( fork of consolekit ). Not just for those examples I've mentioned, but for many more things that above mentioned "kits" do.

Instead of offering another conspiracy theory and feeding it to the OP, you could offer some technical advice that will work. If you feel that he could do better without policykit, give him advice how to replace it with something that will work.

As a final note to the OP, while preventing unprivileged user to even try to type that password would be good thing, good strong password is better thing.

Watch the name calling. Red Hat's stated policy is about making things complex. Brian Stevens, while an executive of Red Hat, stated back in 2006 or so:

And these things do spread from Red Hat usually starting with their almost private sandbox, Fedora.

However, if you want technical advice that will work, go to the earlier posts where I even pointed to the directories and files that need to be changed/examined to prevent PolicyKit from circumventing settings in sudoers

No, it is not name calling, and yes, it is conspiracy theory and some people do like to involve those in posts that require technical advice and not philosophical arguments. You may, or may not be one of those people. And all that there is in that statement is that red hat earns money because technology they work with is complex, not because they make it complex. Work with D-Bus can not be made simple, that is why there are various "kits" out there. If you know for other, more simple way, please share it. Anyway, I'm sure that there are people around with more knowledge than me about that subject.

And yet everything Red Hat has been doing in recent years has been adding to the complexity and difficulty of Linux and so increasing barriers to use. And thus our costs of using Linux in general increase as a result. While you are right d-bus cannot be made simple, it is only one approach to a set of problems. From here d-bus looks like an unnecessarily complex and ill-scoped approach, and thus wrong.

Again, about technical advice, see the files in the directory /var/lib/polkit-1/localauthority/10-vendor.d/ and work out an override to place in /var/lib/polkit-1/localauthority/50-local.d/ mentioned already back in post #21 From the symptoms, the problem is with pkexec (PolicyKit) and not PAM.

Everything? Really? For example?

Great. Care to offer better approach? Lots of people would love less complex things. I'm sure that kernel maintainers would love you for that.

Btw, all this is coming from someone who really has no love for red hat, nor fedora. On other hand, I do not hate them either.

Oh I see. Thank you for clarifying!

See, that really appalls me. I don't want a system that, intentionally or not, creates an "end-run" around my specifically defined settings.

Do any linux distos NOT use pkexec / policykit?

Turbocapitalist - Are those links above what I should examine to limit pkexec / policykit?

Thank you again.

No, it does not allow end-run around your specifically defined settings. It just allows some normal stuff to be executed by non privileged users. Like automounting of DVD and USB, or using wifi.

Of those that do not, Slackware would be your best bet. But expect much more manual work.

If that synaptic thing really bothers you that much, there is one simple solution that you could do, now that I think of it. When you launch synaptic from command line, it should start one for unprivileged users. But, when you click on icon of synaptic in menu, it will launch /usr/bin/synaptic-pkexec in Debian. It might be in some other place on Mint. Use which synaptic-pkexec to find out. When you do, you can change it's permissions so only root can run it. So sudo chmod o-x /usr/bin/synaptic-pkexec should prevent those without sudo privileges to launch it.

dejank - I am grateful for the suggestion and will consider it, but I noticed you referred to launching Synaptic via command line. What about launching Synaptic via GUI input? GUI is what I normally use and it says "Superuser" when I launch it via GUI. Is it possible to restrict this behaviour while using GUI too?

Yes, but pkexec / policykit does have a bit of a learning curve. The Arch link that dejank posted is also helpful in that regard.

When you launch it via GUI, it opens /usr/bin/synaptic-pkexec. So, you could either try to find path it uses to do that, symlink probably and change it to open /usr/bin/synaptic. Or, do as I've suggested you and than non privileged users will not be able to open it at all via gui, but will be able to open synaptic in terminal ( by simply typing synaptic ), but that one will not ask them for password and will run in unprivileged more ( will be able to browse packages, but not to update and install ). And when you want to launch it, open terminal type sudo synaptic, which will open it with root privileges. If you want to change default launch of synaptic, you could probably do that to, by editing file /usr/share/menu/synaptic and changing this line:

to this line:

It could be located somewhere else, I'm looking this on Debian and you are on Mint. But that should give you idea what to do and should probably be solution to launch Synaptic in GUI. But, when you do that, it will run in unprivileged mode. And you will have to use again terminal and sudo synaptic to run it as root. So, as I've already told you, if you want to turn policykit stuff off, you can. But then you will have to do more manual work. Synaptic-pkexec exists to make it easier, and if you have good password you do not have to worry about it. Failed password attempts can be tracked, and number of failed password attempts can be restricted.

There is a way to bypass polkit described here.

Nope, that explains how to make polkit not require password. It is same as running as root all the time, for all users. And that is certainly not something that OP would like.