non-privileged user can start gparted

9 replies [Last post]
sid
sid
Offline
Joined: 02/09/2022

Is it a security bug or intentional that a non-privileged user can start gparted apparently as superuser?

Ark74

I am a member!

I am a translator!

Online
Joined: 07/15/2009

If you have found a reproducible bug, please fill in an issue.

prospero
Offline
Joined: 05/20/2022

I cannot not reproduce this.

Are you by any chance using a live system?

sid
sid
Offline
Joined: 02/09/2022

That is correct, I am using a live system. I did not know there should be a difference between live and installed system for this. In the past neither live nor intalled trisquel systems would allow a non-privileged user to start gparted. So for me this is unexpected change of behavior but maybe I am missing something?

prospero
Offline
Joined: 05/20/2022

How are you logging into that live system?

Ark74

I am a member!

I am a translator!

Online
Joined: 07/15/2009

ubuntu / trisquel live system now days don't require password.

So, since a password is not being used, then it won't ask for one, and since the default user (trisquel) is part of the sudo group then it will have the required permissions to launch applications that might require administrative permissions.

I think you can track this behavior back to toutatis (t6).

This is not the case for a normal user (even in sudo group) on a installed system.

sid
sid
Offline
Joined: 02/09/2022

There are two points I should explain.

First, I do not need to type "sudo gparted", I only need to type "gparted" and gparted will start apparently as superuser. (Only a couple of trisquel versions before, this was impossible, it was necessary to type "sudo gparted" even on live system.)

Second, even though this is with live system, I set sudoer casper file so it looks:
trisquel ALL=(ALL) PASSWD: ALL

Therefore I expect privileged applications or commands should ask for password before to run (or do I mis-understand something here?)

So maybe everything is working the way it is supposed to work but I am failing to understand why this behavior is correct when it was different behavior only a couple of trisquel versions before?

Ark74

I am a member!

I am a translator!

Online
Joined: 07/15/2009

> So maybe everything is working the way it is supposed to work but I am failing to understand why this behavior is correct when it was different behavior only a couple of trisquel versions before?

Please note that every trisquel release is a LTS one for quite sometime, so while we only go from one version to the next, there are 2 years of changes compressed on each one, so the more I'm around I see how one feature I like then on the next it might change a bit, or it might be gone, on the other hand LTS releases give us enough support time to stay on the custom environment we build from our trisquel installation.

So I would argue that's the main reason we all see these changes.

Thank you for your report, and please if you find a reproducible bug, don't hesitate to report it.

Regards o/

sid
sid
Offline
Joined: 02/09/2022

> Thank you for your report, and please if you find a reproducible bug, don't hesitate to report it.

I am just still not sure IF this a bug or if it is intended behavior. It looks like a bug to me but my understanding of intended behavior may be wrong. If this is a bug, I want to report. If it is intended behavior, I want to correct my understanding.

My understanding is that:

1. Even if default user (trisquel) is part of sudo group, it should still be necessary to use "sudo" to launch privilaged applications (eg. "sudo gparted" and not just "gparted"). Only root user should not need to use "sudo".
2. If you set a password for the default user (trisquel) and also make sudoers file for default user (trisquel) to need password, then default user should not be able to launch privileged applications without supplying a password.

Please correct me if I understand above points wrong, I want to learn.

jxself
Offline
Joined: 09/13/2010

"or if it is intended behavior."

I think "ubuntu / trisquel live system now days don't require password" covered the intention. :)

The live environment is intended to be helpful for recovery of an installed system, which will usually require this. I'm going to imagine there's a NOPASSWD entry set "somewhere" to pull this off. If not in the sudoers file itself then through one of the "include" locations. Have you checked everywhere, including inside /etc/sudoers.d/casper? But it sounds like not requiring a password is indeed its intended behavior.