[opensuse-factory] Running YaST-Control-Center without root
Hi, I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this. It requires more password entering if opened without root, which might prove to be annoying. From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ). Affects only Qt version. [1] https://github.com/yast/yast-control-center/commit/d7e96130a2423041b47622be6... LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/04/2019 15.18, Stasiek Michalski wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ).
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I use GTK, and typically I start GUI yast from a terminal where I did "su -" for whatever tasks I many need. - -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXL9yMQAKCRC1MxgcbY1H 1WChAJ49AKhCuDinY3xobt+4TO+TixkouwCfTNj5kj06fR9AZlRISk64AR4QvfI= =5K7T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On wto, Apr 23, 2019 at 10:14 PM, "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/04/2019 15.18, Stasiek Michalski wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ).
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I use GTK, and typically I start GUI yast from a terminal where I did "su -" for whatever tasks I many need.
This scenario would still work, just wouldn't be the default way. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/23/2019 1:14 PM, Carlos E. R. wrote:
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I thought I remembered there being a timeout option with sudo where you could configure it to let you continue running "root tasks" for the next 'X' minutes and it wouldn't ask you for your password again until the time expired.
Seems like that would solve the issue of having to re-enter passwords but allow entering such a password only when actually needed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* L A Walsh <suse@tlinx.org> [04-25-19 12:40]:
On 4/23/2019 1:14 PM, Carlos E. R. wrote:
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I thought I remembered there being a timeout option with sudo where you could configure it to let you continue running "root tasks" for the next 'X' minutes and it wouldn't ask you for your password again until the time expired.
Seems like that would solve the issue of having to re-enter passwords but allow entering such a password only when actually needed.
man 5 sudoers sudoers uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written contain- ing the user ID that was used to authenticate, the terminal session ID, the start time of the session leader (or parent process) and a time stamp (using a monotonic clock if one is available). The user may then use sudo without a password for a short pe- riod of time (5 minutes unless overridden by the timestamp_timeout option). By default, sudoers uses a separate record for each terminal, which means that a user's login sessions are authenticated separately. The timestamp_type option can be used to se- lect the type of time stamp record sudoers will use. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2019 09.11, L A Walsh wrote:
On 4/23/2019 1:14 PM, Carlos E. R. wrote:
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I thought I remembered there being a timeout option with sudo where you could configure it to let you continue running "root tasks" for the next 'X' minutes and it wouldn't ask you for your password again until the time expired.
Correct.
Seems like that would solve the issue of having to re-enter passwords but allow entering such a password only when actually needed.
But when I use a YaST module it can be minutes or hours before I click on another. Mmmm, would not be "that often" but "that many" :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On czw, Apr 25, 2019 at 7:05 PM, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 25/04/2019 09.11, L A Walsh wrote:
On 4/23/2019 1:14 PM, Carlos E. R. wrote:
- From my point of view as user/admin, I would not use it this way, I don't like having to enter the password that often. I thought I remembered there being a timeout option with sudo where you could configure it to let you continue running "root tasks" for the next 'X' minutes and it wouldn't ask you for your password again until the time expired.
Correct.
Seems like that would solve the issue of having to re-enter passwords but allow entering such a password only when actually needed.
But when I use a YaST module it can be minutes or hours before I click on another.
Mmmm, would not be "that often" but "that many" :-)
Entering password every half an hour/an hour doesn't sound that bad, with __correctly__ configured polkit/sudoers user should have sudo-like behaviour (auth for x time) with desktop apps, as they have with cli apps ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ).
Affects only Qt version.
[1] https://github.com/yast/yast-control-center/commit/d7e96130a2423041b47622be6 7d82eda3a78cd96 LCP [Stasiek] https://lcp.world My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict separation between system and user. Entering YaST means the user is going to perform system related tasks. I'm even firmly against having no 'root' but just plain sudo and the user's
Op dinsdag 23 april 2019 15:18:35 CEST schreef Stasiek Michalski: password. To me that is the same as what ( still ) lots of W users do, i.e. work in an admin account. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict separation between system and user. Entering YaST means the user is going to perform system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center. Unless you manually override that in the polkit config of course. ;-)
I'm even firmly against having no 'root' but just plain sudo and the user's password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote:
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict separation between system and user. Entering YaST means the user is going to perform system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center.
Unless you manually override that in the polkit config of course. ;-)
or run `sudo -E yast --qt`
I'm even firmly against having no 'root' but just plain sudo and the user's password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/04/2019 20.09, Stasiek Michalski wrote: ...
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
That default setting is to facilitate the initial installation of the system. Once done the admin should change sudo configuration. That's the meaning of this paragraph: ## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 8:21 PM, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 24/04/2019 20.09, Stasiek Michalski wrote:
...
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
That default setting is to facilitate the initial installation of the system. Once done the admin should change sudo configuration. That's the meaning of this paragraph:
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
The kind of people that go through sudoers files are the ones that want to use the wheel group, I don't really see other use of it, because settings related to methods and not users are located in pam configs ;) The administration documentation doesn't really go in config files, it's not going to be read if you have no idea about config to begin with, there is /usr/share/doc, manpages and official openSUSE Documentation that should inform system administrator about this much better. Expecting that user will know to change the password is unreasonable. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 24 april 2019 20:50:42 CEST schreef Stasiek Michalski:
On śro, Apr 24, 2019 at 8:21 PM, "Carlos E. R."
<robin.listas@telefonica.net> wrote:
On 24/04/2019 20.09, Stasiek Michalski wrote:
...
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
That default setting is to facilitate the initial installation of the system. Once done the admin should change sudo configuration. That's the meaning of this paragraph:
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
The kind of people that go through sudoers files are the ones that want to use the wheel group, I don't really see other use of it, because settings related to methods and not users are located in pam configs ;)
The administration documentation doesn't really go in config files, it's not going to be read if you have no idea about config to begin with, there is /usr/share/doc, manpages and official openSUSE Documentation that should inform system administrator about this much better.
Expecting that user will know to change the password is unreasonable.
LCP [Stasiek] https://lcp.world Wheel group is deprecated AFAIK.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 10:25 PM, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op woensdag 24 april 2019 20:50:42 CEST schreef Stasiek Michalski:
On śro, Apr 24, 2019 at 8:21 PM, "Carlos E. R."
On 24/04/2019 20.09, Stasiek Michalski wrote:
...
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that
<robin.listas@telefonica.net> wrote: policy ;)
That default setting is to facilitate the initial installation of
the
system. Once done the admin should change sudo configuration. That's the meaning of this paragraph:
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
The kind of people that go through sudoers files are the ones that want to use the wheel group, I don't really see other use of it, because settings related to methods and not users are located in pam configs ;)
The administration documentation doesn't really go in config files, it's not going to be read if you have no idea about config to begin with, there is /usr/share/doc, manpages and official openSUSE Documentation that should inform system administrator about this much better.
Expecting that user will know to change the password is unreasonable.
LCP [Stasiek] https://lcp.world Wheel group is deprecated AFAIK.
Well, sudoers still refers to it, you can quite easily enable it in that config. A lot of other (mainly RH based) distros still use wheel, it's an option in anaconda when installing the system (but anaconda also has seperate user and root passwords by default on the other hand). LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 24, 2019 at 4:31 PM Stasiek Michalski <hellcp@opensuse.org> wrote:
On śro, Apr 24, 2019 at 10:25 PM, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op woensdag 24 april 2019 20:50:42 CEST schreef Stasiek Michalski:
On śro, Apr 24, 2019 at 8:21 PM, "Carlos E. R."
On 24/04/2019 20.09, Stasiek Michalski wrote:
...
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that
<robin.listas@telefonica.net> wrote: policy ;)
That default setting is to facilitate the initial installation of
the
system. Once done the admin should change sudo configuration. That's the meaning of this paragraph:
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
The kind of people that go through sudoers files are the ones that want to use the wheel group, I don't really see other use of it, because settings related to methods and not users are located in pam configs ;)
The administration documentation doesn't really go in config files, it's not going to be read if you have no idea about config to begin with, there is /usr/share/doc, manpages and official openSUSE Documentation that should inform system administrator about this much better.
Expecting that user will know to change the password is unreasonable.
LCP [Stasiek] https://lcp.world Wheel group is deprecated AFAIK.
Well, sudoers still refers to it, you can quite easily enable it in that config.
A lot of other (mainly RH based) distros still use wheel, it's an option in anaconda when installing the system (but anaconda also has seperate user and root passwords by default on the other hand).
Since when is "wheel" deprecated? I've never heard of this. In Debian systems, the wheel group was renamed to sudo, but in all other distro families, the wheel group exists and is properly configured by default (except of course, in openSUSE, where it's busted by design). I'd like that to be fixed, but for all the reasons Stasiek mentioned, I haven't gone beyond "hopes and wishes" to fix this in openSUSE. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Neal Gompa schrieb:
On Wed, Apr 24, 2019 at 4:31 PM Stasiek Michalski <hellcp@opensuse.org> wrote:
[...] A lot of other (mainly RH based) distros still use wheel, it's an option in anaconda when installing the system (but anaconda also has seperate user and root passwords by default on the other hand).
Since when is "wheel" deprecated? I've never heard of this. In Debian systems, the wheel group was renamed to sudo, but in all other distro families, the wheel group exists and is properly configured by default (except of course, in openSUSE, where it's busted by design).
Do you have examples of that? To the best of my knowledge adding meaning to the wheel group in SUSE distributions has always been left to the administrator. Ie the operating system creates the group but doesn't use it. So the wheel group could mean anything in production deployments. One use case would be for example to only allow members of the wheel group to call setuid binaries like su/sudo either via file system permissions or by configuration, but still having to enter (means knowing) the root password. Another one would be to allow sudo without even having to enter the root password for members of the wheel group. Means accounts with the wheel group are basically root. That's a very important difference. The wheel group could also be used in arbitrary ways with polkit or for accessing sensitive log files. Due to this legacy we as operating system vendor have to be very careful if we would now suddenly start defining our own meaning for the wheel group. Nevertheless I think it would make sense to have a way to flag user accounts as "administrator accounts". Not necessarily in the sense to directly allow such accounts to carry out privileged operations, nor to prevent accounts without the flag to use su/sudo though. It would rather be a way to signal the system that those accounts normally do not know the root password. As such it's pointless to ask in the first place. An example would be NetworkManager. Something goes wrong with the connection and it asks you for privileges to modify system wide settings. It just shouldn't bother non admin users with that, they can't (and shouldn't) help themselves anyways. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 25, 2019 at 12:17 PM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Neal Gompa schrieb:
On Wed, Apr 24, 2019 at 4:31 PM Stasiek Michalski <hellcp@opensuse.org> wrote:
[...] A lot of other (mainly RH based) distros still use wheel, it's an option in anaconda when installing the system (but anaconda also has seperate user and root passwords by default on the other hand).
Since when is "wheel" deprecated? I've never heard of this. In Debian systems, the wheel group was renamed to sudo, but in all other distro families, the wheel group exists and is properly configured by default (except of course, in openSUSE, where it's busted by design).
Do you have examples of that?
To the best of my knowledge adding meaning to the wheel group in SUSE distributions has always been left to the administrator. Ie the operating system creates the group but doesn't use it. So the wheel group could mean anything in production deployments.
What I mean is that there's no dumb "targetpw" rule. In RH/Fedora, users are not configured into the wheel group by default, but the wheel group works. During installation, you can click a checkbox to mark the user as an administrator, and that makes it so the user is added to the wheel group. Once you have an "admin user", you are allowed to not have a root user that you can log into. In my view, this is generally a good thing as it reduces the number of configured users that could be exploited.
One use case would be for example to only allow members of the wheel group to call setuid binaries like su/sudo either via file system permissions or by configuration, but still having to enter (means knowing) the root password. Another one would be to allow sudo without even having to enter the root password for members of the wheel group. Means accounts with the wheel group are basically root. That's a very important difference.
The wheel group could also be used in arbitrary ways with polkit or for accessing sensitive log files.
Due to this legacy we as operating system vendor have to be very careful if we would now suddenly start defining our own meaning for the wheel group.
Nevertheless I think it would make sense to have a way to flag user accounts as "administrator accounts". Not necessarily in the sense to directly allow such accounts to carry out privileged operations, nor to prevent accounts without the flag to use su/sudo though. It would rather be a way to signal the system that those accounts normally do not know the root password. As such it's pointless to ask in the first place. An example would be NetworkManager. Something goes wrong with the connection and it asks you for privileges to modify system wide settings. It just shouldn't bother non admin users with that, they can't (and shouldn't) help themselves anyways.
SUSE's legacy of sudo configuration is unintuitive and unhelpful. And because it deviates so much from the norm, a lot of graphical tools that fall back to sudo information (or polkit, which itself relies on that) are broken until this is fixed. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 25, Neal Gompa wrote:
Once you have an "admin user", you are allowed to not have a root user that you can log into. In my view, this is generally a good thing as it reduces the number of configured users that could be exploited.
As I did a research on this topic some months ago for another project: Most security experts do disagree with you. And even Ubuntu writes in their security documentation, that the sudo rules and not having a root user that you can log into is the weak spot in their security story and was not done for security reasons, but to avaoid that new users do everything as root and destroy their system by accident. So for supportability reasons. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Apr 25 2019, Thorsten Kukuk <kukuk@suse.de> wrote:
As I did a research on this topic some months ago for another project: Most security experts do disagree with you. And even Ubuntu writes in their security documentation, that the sudo rules and not having a root user that you can log into is the weak spot in their security story and was not done for security reasons, but to avaoid that new users do everything as root and destroy their system by accident. So for supportability reasons.
They probably copied that from MacOSX. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/07/2019 04:42 AM, Andreas Schwab wrote:
On Apr 25 2019, Thorsten Kukuk <kukuk@suse.de> wrote:
As I did a research on this topic some months ago for another project: Most security experts do disagree with you. And even Ubuntu writes in their security documentation, that the sudo rules and not having a root user that you can log into is the weak spot in their security story and was not done for security reasons, but to avaoid that new users do everything as root and destroy their system by accident. So for supportability reasons. They probably copied that from MacOSX.
Andreas.
Probably. Linux users know better. I often tell people running Windows that instead of using the admin account they get out of the box, they should create user accounts and only use the admin account when necessary. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, May 7, 2019 at 3:17 PM, James Knott <james.knott@jknott.net> wrote:
On 05/07/2019 04:42 AM, Andreas Schwab wrote:
On Apr 25 2019, Thorsten Kukuk <kukuk@suse.de> wrote:
As I did a research on this topic some months ago for another project: Most security experts do disagree with you. And even Ubuntu writes in their security documentation, that the sudo rules and not having a root user that you can log into is the weak spot in their security story and was not done for security reasons, but to avaoid that new users do everything as root and destroy their system by accident. So for supportability reasons. They probably copied that from MacOSX.
Andreas.
Probably. Linux users know better. I often tell people running Windows that instead of using the admin account they get out of the box, they should create user accounts and only use the admin account when necessary.
IIRC that was the default with Windows XP and earlier, although even with privileges, Windows' cmd is a joke compared to capabilities of shell, which gives you a very easy option to kill EFI, and brick the machine entirely. Saying that Linux users know better is unfair, I personally started my journey with Linux at age 8, without much guidance from anybody. If EFI existed at the time, I would have bricked more than one computer ;) The userbase consists of people of all ages and experience levels, please don't assume the skills based on platforms. There will always be people that are trying out Linux for fun, and maybe if it doesn't end up bricking their PC, they will consider continuing using it. Linux is way more approachable to everybody, compared to how it was in the past, and I don't see the change in user experience going in other direction anytime soon. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2019 09.58, Ludwig Nussel wrote:
Neal Gompa schrieb:
On Wed, Apr 24, 2019 at 4:31 PM Stasiek Michalski <hellcp@opensuse.org> wrote:
[...] A lot of other (mainly RH based) distros still use wheel, it's an option in anaconda when installing the system (but anaconda also has seperate user and root passwords by default on the other hand).
Since when is "wheel" deprecated? I've never heard of this. In Debian systems, the wheel group was renamed to sudo, but in all other distro families, the wheel group exists and is properly configured by default (except of course, in openSUSE, where it's busted by design).
Do you have examples of that?
I would appreciate some documentation of how is "wheel" intended to be used, specially on openSUSE. What I found ages ago said something like wheel being fascist, and assumed everybody knew, so I did not investigate further ;-)
To the best of my knowledge adding meaning to the wheel group in SUSE distributions has always been left to the administrator. Ie the operating system creates the group but doesn't use it. So the wheel group could mean anything in production deployments.
One use case would be for example to only allow members of the wheel group to call setuid binaries like su/sudo either via file system permissions or by configuration, but still having to enter (means knowing) the root password. Another one would be to allow sudo without even having to enter the root password for members of the wheel group. Means accounts with the wheel group are basically root. That's a very important difference.
Or allow sudo with user password for those users in wheel group. That would suit me. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 25, Carlos E. R. wrote:
I would appreciate some documentation of how is "wheel" intended to be used, specially on openSUSE.
There is no "intended to be used" on openSUSE, every system administrator is free to use it the way he needs it. I use it together with pam_wheel and su, e.g. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On czw, Apr 25, 2019 at 10:00 PM, Thorsten Kukuk <kukuk@suse.de> wrote:
On Thu, Apr 25, Carlos E. R. wrote:
I would appreciate some documentation of how is "wheel" intended to be used, specially on openSUSE.
There is no "intended to be used" on openSUSE, every system administrator is free to use it the way he needs it.
I use it together with pam_wheel and su, e.g.
+1 to this, openSUSE's role in all this should be to provide sane defaults, for users that won't bother with modifying all that jazz. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 24. April 2019, 20:09:04 schrieb Stasiek Michalski:
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote: or run `sudo -E yast --qt`
Sure, or use "su -", xdg-su, kdesu, gnomesu... ;-) Btw, kdesu can be configured to use sudo instead, in which case it would follow the sudo config which would also allow to ask it the *user* password instead. But I guess that's getting off-topic now.... ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
As I see it, that's a compromise to ease the life of "simple" users. Like the default ("easy") polkit settings, that allow users to install updates (not new packages) via PackageKit without entering the root password. OTOH, exactly that also can cause confusion if that "simple" user changes their password afterwards. Personally, I still prefer that strict differentiation between a/the user and root as well though. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 8:46 PM, Wolfgang Bauer <wbauer@tmo.at> wrote:
Am Mittwoch, 24. April 2019, 20:09:04 schrieb Stasiek Michalski:
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote: or run `sudo -E yast --qt`
Sure, or use "su -", xdg-su, kdesu, gnomesu... ;-)
Btw, kdesu can be configured to use sudo instead, in which case it would follow the sudo config which would also allow to ask it the *user* password instead. But I guess that's getting off-topic now.... ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
As I see it, that's a compromise to ease the life of "simple" users. Like the default ("easy") polkit settings, that allow users to install updates (not new packages) via PackageKit without entering the root password.
There is that cool concept of "supported" packages/repos in PackageKit that would allow only packages from vendor specified repos to be updated/installed without password, although nobody implemented that stuff for zypp backend.
OTOH, exactly that also can cause confusion if that "simple" user changes their password afterwards.
Personally, I still prefer that strict differentiation between a/the user and root as well though.
Not planning to take that away currently ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 24 april 2019 20:46:47 CEST schreef Wolfgang Bauer:
Am Mittwoch, 24. April 2019, 20:09:04 schrieb Stasiek Michalski:
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote: or run `sudo -E yast --qt`
Sure, or use "su -", xdg-su, kdesu, gnomesu... ;-)
Btw, kdesu can be configured to use sudo instead, in which case it would follow the sudo config which would also allow to ask it the *user* password instead. But I guess that's getting off-topic now.... ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
As I see it, that's a compromise to ease the life of "simple" users. Like the default ("easy") polkit settings, that allow users to install updates (not new packages) via PackageKit without entering the root password.
OTOH, exactly that also can cause confusion if that "simple" user changes their password afterwards.
Personally, I still prefer that strict differentiation between a/the user and root as well though.
Couldn't agree more. Not based on sheer technical reasoning, but on experiences..... If I install on someone else's machines, I create a 'beheerder' ( dutch for admin ) account, use that to bring everything to 'complete', then let the user use his creds to use the desktop. If they need a DE to accomplish admin tasks the can use that account without changing settings in their own.
Kind Regards, Wolfgang
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 24 april 2019 20:09:04 CEST schreef Stasiek Michalski:
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote:
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict
separation
between system and user. Entering YaST means the user is going to
perform
system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center.
Unless you manually override that in the polkit config of course. ;-)
or run `sudo -E yast --qt`
I'm even firmly against having no 'root' but just plain sudo and
the user's
password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
As the first user, yes. What if you have multiple users?
LCP [Stasiek] https://lcp.world
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 10:25 PM, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op woensdag 24 april 2019 20:09:04 CEST schreef Stasiek Michalski:
On śro, Apr 24, 2019 at 8:05 PM, Wolfgang Bauer <wbauer@tmo.at> wrote:
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict
separation
between system and user. Entering YaST means the user is going to
perform
system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center.
Unless you manually override that in the polkit config of course. ;-)
or run `sudo -E yast --qt`
I'm even firmly against having no 'root' but just plain sudo and
the user's
password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Although, installer's default is also to have root have the same password as user, which makes me question security of that policy ;)
As the first user, yes. What if you have multiple users?
There is a reason DE settings let you choose between making `Administrator` or `Standard` user when creating a new user on the system. Without wheel group it's pointless, but it's there. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 24 april 2019 20:05:38 CEST schreef Wolfgang Bauer:
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict separation between system and user. Entering YaST means the user is going to perform system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center.
That's what I don't want to change.
Unless you manually override that in the polkit config of course. ;-)
I'm even firmly against having no 'root' but just plain sudo and the user's password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Kind Regards, Wolfgang
I know, but I also know it works different in other distros and I would not like to see that happen. Some friends use *buntu derivates and have no idea about what is system and what is user. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 10:24 PM, Knurpht-openSUSE <knurpht@opensuse.org> wrote:
Op woensdag 24 april 2019 20:05:38 CEST schreef Wolfgang Bauer:
My 2 cents: Please, NO !!! One of the things I've always loved about openSUSE is the strict separation between system and user. Entering YaST means the user is going to
Am Mittwoch, 24. April 2019, 18:56:49 schrieb Knurpht-openSUSE: perform
system related tasks.
You'd still have to enter the root password though, just later when you call any module from YaST Control Center.
That's what I don't want to change.
Unless you manually override that in the polkit config of course. ;-)
I'm even firmly against having no 'root' but just plain sudo and the user's password.
Even "sudo" requires the *root* password in openSUSE's default config, as you should know. ;-)
Kind Regards, Wolfgang
I know, but I also know it works different in other distros and I would not like to see that happen. Some friends use *buntu derivates and have no idea about what is system and what is user.
Alright, but in what way does YaST alert that, with default openSUSE configuration you would still use user password to access YaST and the only module plastered with warnings is the partitioner. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Stasiek, On Tue, 2019-04-23 at 15:18 +0200, Stasiek Michalski wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
Short story: +1 from my side. Longer justification: It's great to see some movement in this direction. I see this as being a very useful change for the following reason. In my opinion, the root password prompt should deferred for as long as possible and be asked of the user only (but always!) when applying changes to the root configuration. For example, a non-admin user should still be able to open up YaST's software management module to view the list of available and installed packages and patterns on their system; however, only if they choose to make modifications to this list, e.g. add or remove some packages and hit "OK", that is when the root password prompt should pop up. With the current YaST CC (e.g. in Tumbleweed) this is certainly not the case. Indeed, it is kind of weird that I can simply use zypper to see the list of installed packages on my system without using the root password, but the first thing I have to do when launching YaST's SW management module is to key in the root password. I understand that your patch doesn't fix this entirely right now (but you were probably hinting at something like this at the end when mentioning Polkit integration, right?); I am simply putting my idea of "ideal behaviour" out here. It also potentially aids security in the sense that if an admin absent- mindedly leaves the main control-centre open on a user's desktop session (e.g. after helping out a colleague install some packages on their desktop without giving the user the admin password), the non- admin user would still have to authenticate themselves should they want to launch a module and actually make changes. Since no actual changes can be made to the system directly from the YaST CC window -- which is but only a launcher for individual YaST modules, I see no reason why the root password should be required when launching the CC itself. So, +1. Thanks and best wishes.
From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ).
Affects only Qt version.
[1] https://github.com/yast/yast-control-center/commit/d7e96130a2423041b47622be6... LCP [Stasiek] https://lcp.world
-- Atri Bhattacharya Wed 24 Apr 21:16:59 CEST 2019 Sent from openSUSE Tumbleweed 20190420 on my laptop. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On śro, Apr 24, 2019 at 9:38 PM, badshah400@gmail.com wrote:
Hi Stasiek,
On Tue, 2019-04-23 at 15:18 +0200, Stasiek Michalski wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
Short story: +1 from my side.
Longer justification: It's great to see some movement in this direction. I see this as being a very useful change for the following reason. In my opinion, the root password prompt should deferred for as long as possible and be asked of the user only (but always!) when applying changes to the root configuration. For example, a non-admin user should still be able to open up YaST's software management module to view the list of available and installed packages and patterns on their system; however, only if they choose to make modifications to this list, e.g. add or remove some packages and hit "OK", that is when the root password prompt should pop up.
With the current YaST CC (e.g. in Tumbleweed) this is certainly not the case. Indeed, it is kind of weird that I can simply use zypper to see the list of installed packages on my system without using the root password, but the first thing I have to do when launching YaST's SW management module is to key in the root password. I understand that your patch doesn't fix this entirely right now (but you were probably hinting at something like this at the end when mentioning Polkit integration, right?); I am simply putting my idea of "ideal behaviour" out here.
There are scenarios when even for refreshing repos you would need a password, but in general, yes, I wish we did not overuse root permission when not required. Qt in root behaves weirdly depending on desktop environment, which a lot of people did hit when I was patching YaST to use fd.o icon themes properly (although was quite obvious with various bugs with widget theming even before that). There is some opposition in YaST team, considering submitting polkit policies to factory is a pain, and the task of porting will take months to complete the entire stack (like 70 modules and some support libs) and other factors, which for the sake of staying sane myself I will omit.
It also potentially aids security in the sense that if an admin absent- mindedly leaves the main control-centre open on a user's desktop session (e.g. after helping out a colleague install some packages on their desktop without giving the user the admin password), the non- admin user would still have to authenticate themselves should they want to launch a module and actually make changes.
Since no actual changes can be made to the system directly from the YaST CC window -- which is but only a launcher for individual YaST modules, I see no reason why the root password should be required when launching the CC itself.
+1 on this LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/24/19 9:38 PM, badshah400@gmail.com wrote:
Hi Stasiek,
On Tue, 2019-04-23 at 15:18 +0200, Stasiek Michalski wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
Short story: +1 from my side.
Short story: I agree with badshah400, +1 from my side.
Longer justification: In my opinion, the root password prompt should deferred for as long as possible and be asked of the user only (but always!) when applying changes to the root configuration.
Fully agreed
For example, a non-admin user should still be able to open up YaST's software management module to view the list of available and installed packages and patterns on their system; however, only if they choose to make modifications to this list, e.g. add or remove some packages and hit "OK", that is when the root password prompt should pop up.
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
With the current YaST CC (e.g. in Tumbleweed) this is certainly not the case. Indeed, it is kind of weird that I can simply use zypper to see the list of installed packages on my system without using the root password, but the first thing I have to do when launching YaST's SW management module is to key in the root password. I understand that your patch doesn't fix this entirely right now (but you were probably hinting at something like this at the end when mentioning Polkit integration, right?); I am simply putting my idea of "ideal behaviour" out here.
As explained above, that "ideal behavior" may not by so ideal. As YaST is conceived right now, the win would be marginal. In 99% cases it would end up asking for the root password very soon. Certainly before the user clicks "Ok" or "Finish" and certainly in a less consistent way.
It also potentially aids security in the sense that if an admin absent- mindedly leaves the main control-centre open on a user's desktop session
Fully agreed.
Since no actual changes can be made to the system directly from the YaST CC window -- which is but only a launcher for individual YaST modules, I see no reason why the root password should be required when launching the CC itself.
Fully agreed. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-04-25 at 21:22 +0200, Carlos E. R. wrote:
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password.
This can possibly be done by an info box when a particular module starts up, I guess, though I can't imagine how any user would simply assume that they would be able to apply changes to root configuration/filesystem without requiring some kind of privilege escalation. Actually, I wouldn't even mind requiring root privileges for some YaST modules from the moment they are launched (like firewall, as Ancor has pointed out). This would be nonetheless many times better than having to key in root password for simply looking at installed/available packages, configured repositories, network proxy settings, and/or network IP address (when using wicked), all of which can be done without root access from the terminal anyway (e.g. using `zypper` and `ip` as non-root user). In openSUSE, the answer to a user's question about looking up installed packages via a GUI interface is "not unless you are root". It shouldn't have to be. Cheers. -- Atri Bhattacharya Fri 26 Apr 02:42:43 CEST 2019 Sent from openSUSE Tumbleweed 20190420 on my laptop. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On pią, Apr 26, 2019 at 2:52 AM, badshah400@gmail.com wrote:
On Thu, 2019-04-25 at 21:22 +0200, Carlos E. R. wrote:
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password.
This can possibly be done by an info box when a particular module starts up, I guess, though I can't imagine how any user would simply assume that they would be able to apply changes to root configuration/filesystem without requiring some kind of privilege escalation.
I would assume that for administrator user (as in wheel user), we could assume that they have a root password (or their own, depending on wheel config), for non-wheel, they should get a pop-up, considering they shouldn't probably even be touching that stuff to begin with. But that would require working wheel ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/04/2019 02.59, Stasiek Michalski wrote:
On pią, Apr 26, 2019 at 2:52 AM, badshah400@gmail.com wrote:
On Thu, 2019-04-25 at 21:22 +0200, Carlos E. R. wrote:
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password.
This can possibly be done by an info box when a particular module starts up, I guess, though I can't imagine how any user would simply assume that they would be able to apply changes to root configuration/filesystem without requiring some kind of privilege escalation.
I would assume that for administrator user (as in wheel user), we could assume that they have a root password (or their own, depending on wheel config), for non-wheel, they should get a pop-up, considering they shouldn't probably even be touching that stuff to begin with.
As user in a machine where I was not root, I tried more than once to *look* at how things were done in order to learn and then do them at my own computer back home.
But that would require working wheel ;)
LCP [Stasiek] https://lcp.world
-- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/26/19 8:52 AM, badshah400@gmail.com wrote:
On Thu, 2019-04-25 at 21:22 +0200, Carlos E. R. wrote:
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password.
This can possibly be done by an info box when a particular module starts up, I guess, though I can't imagine how any user would simply assume that they would be able to apply changes to root configuration/filesystem without requiring some kind of privilege escalation.
Actually, I wouldn't even mind requiring root privileges for some YaST modules from the moment they are launched (like firewall, as Ancor has pointed out). This would be nonetheless many times better than having to key in root password for simply looking at installed/available packages, configured repositories, network proxy settings, and/or network IP address (when using wicked), all of which can be done without root access from the terminal anyway (e.g. using `zypper` and `ip` as non-root user). In openSUSE, the answer to a user's question about looking up installed packages via a GUI interface is "not unless you are root". It shouldn't have to be.
Cheers.
I think it depends on how often Yast and the modules are being used. Personally I prefer it the way it is now and have to enter the root password only once when Yast is launched and be done. I really do not wish being prompted a password dialog every time and for each module. -- Maurizio Galli (MauG) Xfce Team https://en.opensuse.org/Portal:Xfce -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/04/2019 10:35, Maurizio Galli (MauG) wrote:
On 4/26/19 8:52 AM, badshah400@gmail.com wrote:
On Thu, 2019-04-25 at 21:22 +0200, Carlos E. R. wrote:
On 25/04/2019 10.19, Ancor Gonzalez Sosa wrote:
Just a note here. In some cases, asking the password only at the end (when writing configuration) would make sense. But in general is not that simple. YaST is an interactive tool and, as such, it performs several tasks that would need root permission in several points of the user interaction. E.g. installing some package that is required to continue, reading some protected configuration, adjusting the firewall to be able to explore the network, starting or stopping a service, refreshing the list of repos...
Being able to fire up YaST and do some configuration work, then at the end see it asking for the root password could be nasty surprise if the user doesn't have it. After all the work, not being able to continue... At least he should get told at the start that to save changes he needs the root password.
This can possibly be done by an info box when a particular module starts up, I guess, though I can't imagine how any user would simply assume that they would be able to apply changes to root configuration/filesystem without requiring some kind of privilege escalation.
Actually, I wouldn't even mind requiring root privileges for some YaST modules from the moment they are launched (like firewall, as Ancor has pointed out). This would be nonetheless many times better than having to key in root password for simply looking at installed/available packages, configured repositories, network proxy settings, and/or network IP address (when using wicked), all of which can be done without root access from the terminal anyway (e.g. using `zypper` and `ip` as non-root user). In openSUSE, the answer to a user's question about looking up installed packages via a GUI interface is "not unless you are root". It shouldn't have to be.
Cheers.
I think it depends on how often Yast and the modules are being used. Personally I prefer it the way it is now and have to enter the root password only once when Yast is launched and be done. I really do not wish being prompted a password dialog every time and for each module.
Even keeping this idea it would be much better if the UI ran as the user and asked for the password at the start (if thats what people preferred, you could maybe just add a prompt for password at launch setting). I'm also all for using polkit more and this is probably a good starting place for that. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
+1. User customizations would finally apply to YaST on Plasma, including global menus and title bar application menus. On 2019-04-23 09:18:35 EDT, Stasiek Michalski <hellcp@opensuse.org> wrote:
Hi,
I made a patch for YaST CC which enables it to run without root permissions, and starts separate modules as root instead (when it needs them with root permissions) [1], however I'm not sure how you might feel about this.
It requires more password entering if opened without root, which might prove to be annoying.
From my point of view, it fixes quite a few bugs, with theming of this module, as this is the module with the biggest set of icons. It also would work just fine with Wayland (although it could still have issues with starting modules in Wayland session, considering it doesn't set an env variable for XWayland). It also allows modules that don't require root to be started without permissions, which is convenient for at least two modules (and would be even more convinient if Polkit started being used in YaST ;) ).
Affects only Qt version.
[1] https://github.com/yast/yast-control-center/commit/d7e96130a2423041b47622be6... LCP [Stasiek] https://lcp.world
Hi all, I am happy to see this discussion. I started to thought that I was the only one complaining about the way root/sudoers/authentication-in-yast works in openSUSE/SLE. I personally find Stasiek’s current proposal bad for UX, since getting asked more than one time for the password is more frustrating than getting asked only one. It is good to hear different voices and opinions, since I think that to find the right way to do it, we have to find consensus of what we want, what basic users want, what system administrators want... I already raised this conversation with Ludwig and even created 2 tickets in fate. But, fate was closed and the tickets lost. My proposal was to add a user group “admin” by default, add the first user to this group and remove the setting “Defaults targetpw” from /etc/sudoers This way, a user in the group admin would have root rights with its password, which is expected for an admin account. Giving and removing root rights to a user would be so simple as adding it to and removing it from the admin group. sudo can do all the job. If an account is compromised, it can be disabled and removed from the group without affecting other users. I would be against disabling root user by default. I think root should be available for emergencies, rescue system, etc. But, I think root should not be used as the system administrator user. With sudo rules, it can be avoided that a user executes jumping privileges programs, like vim. Instead of that, the filesystem permissions should be used to allow an admin user make modifications. Configuration files under /etc would need to have group owner “admin”, so that an admin user can execute vim as non-root to edit the file. Of course such think needs to be carefully planned and audited by security experts to cover holes. What do you all think? I want to make linux desktop distributions more user friendly (not only geek/IT-scientist friendly), and for that we need to make UX "non-geek first". The defaults need to be the best possible for them, but always allowing the experienced user to set up the things different. Specifically I am thinking on Leap. Tumbleweed isn’t a good candidate for non-geeks, but Leap is. I think that it is ok that Tumbleweed is aimed for geeks. If not possible to change Tumbleweed nor SLE, I will at least beg to change Leap in that regard. Kind Regards Sergio-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, I will start off with a no, but let's get through this ;)
I am happy to see this discussion. I started to thought that I was the only one complaining about the way root/sudoers/authentication-in-yast works in openSUSE/SLE.
I personally find Stasiek’s current proposal bad for UX, since getting asked more than one time for the password is more frustrating than getting asked only one.
I find the proposal reasonable in case of polkit, sudo mode would enable user to execute administrative stuff only for some time, with limitless amount of changes. This way if admin performs all the changes they need to do within the timeframe, they do not have to enter the password more than one time, but when they leave to do other stuff, and forget to close any of the modules, third party can't just change stuff without knowing the password (assuming they show up after the time has run out). Any other model leaves the possibility to run stuff on behalf of root user without a limited timeframe, with the possibility to be compromised by another person in the office, or requires a lot of passwords to execute anything, which is frustrating and pointless considering existing solutions (ie Polkit) already fix that. You could introduce automated closing of YaST windows after some time of inactivity, but considering that Wayland doesn't allow you to track user's activity outside of the application, it wouldn't work very well with it...
It is good to hear different voices and opinions, since I think that to find the right way to do it, we have to find consensus of what we want, what basic users want, what system administrators want... I already raised this conversation with Ludwig and even created 2 tickets in fate. But, fate was closed and the tickets lost.
You can still view the tickets https://features.opensuse.org/ ;)
My proposal was to add a user group “admin” by default, add the first user to this group and remove the setting “Defaults targetpw” from /etc/sudoers This way, a user in the group admin would have root rights with its password, which is expected for an admin account. Giving and removing root rights to a user would be so simple as adding it to and removing it from the admin group. sudo can do all the job. If an account is compromised, it can be disabled and removed from the group without affecting other users.
How does that differ from suggested route with wheel? It's a group of users with permissions to do "admin stuff", which is present on almost every Linux, BSD and Unix system. Assuming that the first user is admin is not a viable way to deal with it, it would be better if it was an option during installation user creation. And in any case, you can remove or disable any user if you got permissions to do so.
I would be against disabling root user by default. I think root should be available for emergencies, rescue system, etc. But, I think root should not be used as the system administrator user.
Also shouldn't have the same password as the first user by default, if we are going the wheel route.
With sudo rules, it can be avoided that a user executes jumping privileges programs, like vim. Instead of that, the filesystem permissions should be used to allow an admin user make modifications. Configuration files under /etc would need to have group owner “admin”, so that an admin user can execute vim as non-root to edit the file. Of course such think needs to be carefully planned and audited by security experts to cover holes.
This is going a little far, especially since you are probably expecting to run various applications with that user, which is not going to be safe if you just let them access everything without asking questions. This also extends third party access issue outside of su windows, it's a bad idea.
What do you all think?
I want to make linux desktop distributions more user friendly (not only geek/IT-scientist friendly), and for that we need to make UX "non-geek first". The defaults need to be the best possible for them, but always allowing the experienced user to set up the things different. Specifically I am thinking on Leap. Tumbleweed isn’t a good candidate for non-geeks, but Leap is. I think that it is ok that Tumbleweed is aimed for geeks. If not possible to change Tumbleweed nor SLE, I will at least beg to change Leap in that regard.
SLE is the base for Leap, I doubt that this important part of system would be changed without taking care of it everywhere. Also Tumbleweed is a great daily driver for anybody (at least we are trying our best to make it be like that, with testing), you should try it out ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, a side note On May 12 00:04 Sergio Lindo wrote (excerpt):
Specifically I am thinking on Leap. Tumbleweed isn?t a good candidate for non-geeks, but Leap is. I think that it is ok that Tumbleweed is aimed for geeks. If not possible to change Tumbleweed nor SLE, I will at least beg to change Leap in that regard.
in general that won't work because all inherit from Factory/Tumbleweed. I.e. in general one cannot have things different in Leap compared to Tumbleweed and SLE because Leap inherits the basic things from Tumbleweed and SLE. But I don't know if "Running YaST-Control-Center" is a basic thing or if it could behave different in Leap compared to Tumbleweed and SLE. A bit more details: Things get first developed in OBS devel projects.
From OBS devel projects things get into openSUSE:Factory / openSUSE Tumbleweed.
At some point in time things from openSUSE:Factory / openSUSE Tumbleweed get into the next SUSE Linux Enterprise version.
From SUSE Linux Enterprise the basic things get into openSUSE Leap.
So openSUSE Leap inherits the basic things from openSUSE Tumbleweed via SUSE Linux Enterprise. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - HRB 21284 (AG Nuernberg) GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (18)
-
Ancor Gonzalez Sosa -
Andreas Schwab -
badshah400＠gmail.com -
Carlos E. R. -
James Knott -
Johannes Meixner -
Knurpht-openSUSE -
L A Walsh -
Ludwig Nussel -
Maurizio Galli (MauG) -
Neal Gompa -
Noah Davis -
Patrick Shanahan -
Sergio Lindo -
Simon Lees -
Stasiek Michalski -
Thorsten Kukuk -
Wolfgang Bauer