Troubles with sudo - and the fix for it
Dear Tumbleweed users, At a perfectlty bad moment, a snapshot with a configuration change for sudo went out and me not being around on the weekend made this problem even worse for you. Background situation: a user requested the sudo configuration to be changed to no longer ask for the 'target user's password', but rather ask for the user willing to become somebody else's password (as other distros do) That change was submitted to Factory and was unfortunately not identified as being really bad for our existing users. So it went out in snapshot 1103 (published Friday evening) Over the weekend, many of you have struggled with this new default. Understandably so. As the change did not take into account ANY user that never had the need to change the sudo config, because it just worked for them. As this change is definitively bad in its current form I have reverted the sudo package to the state it was before snapshot 1103 and published the same version into the openSUSE Tumbleweed update channel. If you get the sudo version from there, your configuration shold start working again without further changes (if you did not change the config since then! Otherwise rpm will create an .rpmnew file and NOT replace your local modied version) Apologies at this place for the trouble caused to you. Of course I will also request openQA to also test the DEFAULT configuration provided - allowing us to spot such issues hopefully before sending them out to users ever again. Thank you very much for your understanding! Let's get this back on track and let's keep having a lot of fun Best regards, Dominique
Thank You for the explanation, Dominique. :-) Dne pondělí 7. listopadu 2022 9:41:57 CET, Dominique Leuenberger / DimStar napsal(a):
Background situation: a user requested the sudo configuration to be changed to no longer ask for the 'target user's password', but rather ask for the user willing to become somebody else's password (as other distros do) As this change is definitively bad in its current form I have reverted the sudo package to the state it was before snapshot 1103 and published the same version into the openSUSE Tumbleweed update channel.
If the original motivation was to align with other distros, if I get it correctly, now we are just reverting back to openSUSE default, so different state than other distros; so will there be any change towards "general consensus", ideally with some automated migration? I added myself into "wheel" group and uncommented in /etc/sudoers "%wheel ALL=(ALL:ALL) ALL", which is fine, but of course in case of automated migration I wouldn't even notice change. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Mon, Nov 07, Vojtěch Zeisek wrote:
Dne pondělí 7. listopadu 2022 9:41:57 CET, Dominique Leuenberger / DimStar napsal(a):
Background situation: a user requested the sudo configuration to be changed to no longer ask for the 'target user's password', but rather ask for the user willing to become somebody else's password (as other distros do) As this change is definitively bad in its current form I have reverted the sudo package to the state it was before snapshot 1103 and published the same version into the openSUSE Tumbleweed update channel.
If the original motivation was to align with other distros, if I get it correctly, now we are just reverting back to openSUSE default, so different state than other distros; so will there be any change towards "general consensus", ideally with some automated migration? I added myself into "wheel" group and uncommented in /etc/sudoers "%wheel ALL=(ALL:ALL) ALL", which is fine, but of course in case of automated migration I wouldn't even notice change. :-)
The motiviation was not to align with other distros, but to fix the usage of sudo as it as designed. openSUSE is using sudo as "modern implementation of su" instead of "sudo". With the current setup, you can replace sudo with su in most cases. The motivation was to configure sudo to work as it was designed for and for security reasons. And mid- to longterm, we need to find a way to change the defaults for sudo to match peoples expectation. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Mon, Nov 7, 2022 at 7:33 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Mon, Nov 07, Vojtěch Zeisek wrote:
Dne pondělí 7. listopadu 2022 9:41:57 CET, Dominique Leuenberger / DimStar napsal(a):
Background situation: a user requested the sudo configuration to be changed to no longer ask for the 'target user's password', but rather ask for the user willing to become somebody else's password (as other distros do) As this change is definitively bad in its current form I have reverted the sudo package to the state it was before snapshot 1103 and published the same version into the openSUSE Tumbleweed update channel.
If the original motivation was to align with other distros, if I get it correctly, now we are just reverting back to openSUSE default, so different state than other distros; so will there be any change towards "general consensus", ideally with some automated migration? I added myself into "wheel" group and uncommented in /etc/sudoers "%wheel ALL=(ALL:ALL) ALL", which is fine, but of course in case of automated migration I wouldn't even notice change. :-)
The motiviation was not to align with other distros, but to fix the usage of sudo as it as designed. openSUSE is using sudo as "modern implementation of su" instead of "sudo". With the current setup, you can replace sudo with su in most cases. The motivation was to configure sudo to work as it was designed for and for security reasons. And mid- to longterm, we need to find a way to change the defaults for sudo to match peoples expectation.
Why not leverage the sudo "lecture" functionality to warn users of the pending change, reference some documentation detailing the change and recommendations to adjust their configurations, do this for a few upgrade cycles, and finally backout the lecture mods and set the default sudo configuration. Just a thought.
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Mon, 7 Nov 2022 13:33:24 +0100, Thorsten Kukuk wrote:
The motiviation was not to align with other distros, but to fix the usage of sudo as it as designed.
It seems to me that the right thing to do is to not break peoples' installations, but to use the desired "new" behaviour on new installations. At best, for those who have a configuration that's working for them, we could use what Darin suggests (the lecture facility) to display a message, but do it without changing the user's chosen behaviour. Leave the choice to change the configuration up to the user. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Mon, Nov 07, 2022 at 04:35:46PM -0000, Jim Henderson wrote:
On Mon, 7 Nov 2022 13:33:24 +0100, Thorsten Kukuk wrote:
The motiviation was not to align with other distros, but to fix the usage of sudo as it as designed.
It seems to me that the right thing to do is to not break peoples' installations, but to use the desired "new" behaviour on new installations.
At best, for those who have a configuration that's working for them, we could use what Darin suggests (the lecture facility) to display a message, but do it without changing the user's chosen behaviour. Leave the choice to change the configuration up to the user.
Dominique has reverted sudo to the previous sudo behaviour in the meantime. Ciao, Marcus
On Mon, 7 Nov 2022 17:37:52 +0100, Marcus Meissner wrote:
Dominique has reverted sudo to the previous sudo behaviour in the meantime.
Yep, saw that discussion as well. I do think that a best practice really should be not to mess with a user's configuration - as we learned, doing that and only announcing it on a mailing list that the user may or may not follow leads to a fair number of problems. The only exception that I can think of where it would be acceptable to change a user's configured system is if the existing configuration exposes a serious security issue (ie, something that there's a CVE bulletin on). And even then, there should be some sort of notification during the update process to let them know - don't depend on people being subscribed to mailing lists or other places where that information is easily lost amongst other information. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 11/7/22 17:43, Jim Henderson wrote:
On Mon, 7 Nov 2022 17:37:52 +0100, Marcus Meissner wrote:
Dominique has reverted sudo to the previous sudo behaviour in the meantime.
Yep, saw that discussion as well.
I do think that a best practice really should be not to mess with a user's configuration
But the hard problem is to determine what "a user's configuration" really means. AFAICS you can only technically check whether the package's default config file was changed or not. Nothing else. You cannot… … technically determine whether the user deliberately wants to stick indefinitely to the implied defaults. … know whether the user really prefers default values for new config values introduced upstream or would rather prefer (part of) the distribution's default config file. Any many more fuzzy issues like this... However a user (or admin) who really wants to ensure deterministic behaviour can generate a custom config file and the package update should not change that. In particular: If you rely on sudo you should make yourself familiar with /etc/sudoers on roll out your own. Especially this also applies to sshd_config, nsswitch.conf and other login-related config you need to fix your system. Ciao, Michael.
On Mon, 7 Nov 2022 20:11:41 +0100, Michael Ströder wrote:
On 11/7/22 17:43, Jim Henderson wrote:
On Mon, 7 Nov 2022 17:37:52 +0100, Marcus Meissner wrote:
Dominique has reverted sudo to the previous sudo behaviour in the meantime.
Yep, saw that discussion as well.
I do think that a best practice really should be not to mess with a user's configuration
But the hard problem is to determine what "a user's configuration" really means.
AFAICS you can only technically check whether the package's default config file was changed or not. Nothing else.
You cannot…
… technically determine whether the user deliberately wants to stick indefinitely to the implied defaults.
That's the user's choice, and the user's choice alone. We can educate the user as to why the defaults were changed, but only they can (and should) make changes to a configuration that they're using.
… know whether the user really prefers default values for new config values introduced upstream or would rather prefer (part of) the distribution's default config file.
Again, that's the user's choice. Not the project's choice to make. Just don't mess with an existing configuration.
Any many more fuzzy issues like this...
However a user (or admin) who really wants to ensure deterministic behaviour can generate a custom config file and the package update should not change that. In particular: If you rely on sudo you should make yourself familiar with /etc/sudoers on roll out your own. Especially this also applies to sshd_config, nsswitch.conf and other login-related config you need to fix your system.
As a sysadmin with more decades of experience than I care to admit to, *nobody* should be making changes to my systems' configurations without my consent. *NOBODY*, period. If I upgrade packages, I expect the binary code to be updated and the config files to be left alone unless the upgraded files somehow are incompatible with the configuration - and then I expect to be informed during the upgrade (not through a mailing list that I may not even be aware of). Keep your hands off my configuration files, and if you *must* make a change, make absolutely sure that the changes (and reasons for them) are *very clearly* advertised *on my system*. It really is that simple. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 11/7/22 23:43, Jim Henderson wrote:
*nobody* should be making changes to my systems' configurations without my consent. *NOBODY*, period. If I upgrade packages, I expect the binary code to be updated and the config files to be left alone unless the upgraded files somehow are incompatible with the configuration
Then you should simply not use mainstream distros at all because all of them deal with configs. A Linux distribution has conflicting goals to be solved by packagers: 1. Provide a default configuration for unexperienced users/admins to have a working system with some services running which also means introducing new config parameters during updates. 2. Keep everything working also after updates for every system on the planet, e.g. by not applying "new" configs. I presume nobody has a silver bullet to solve this conflict. When developing Æ-DIR's ansible roles for various the mainstream distros I kept constantly fighting against too much pseudo config management in the distro's packages. But I have to admit that I can somewhat understand why the packagers are adding config stuff to make things work directly. My solution for critical stuff is 1. to use completely separate config files whereever possible. 2. to install separate systemd service units referencing these separate config files. 3. to use config management so issues can be fixed simply by re-applying the config in a idempotent way. 4. to create custom packages for some rare cases. As said everything related to login/sudo or anything else needed to run your config management procedures can get tricky. You should have fallback options prepared on your critical systems. Ciao, Michael.
On Tue, 8 Nov 2022 00:52:08 +0100, Michael Ströder wrote:
On 11/7/22 23:43, Jim Henderson wrote:
*nobody* should be making changes to my systems' configurations without my consent. *NOBODY*, period. If I upgrade packages, I expect the binary code to be updated and the config files to be left alone unless the upgraded files somehow are incompatible with the configuration
Then you should simply not use mainstream distros at all because all of them deal with configs.
We can - and should - do better. Let's not just say "everyone messes with users' config files and that's just thew way it is".
A Linux distribution has conflicting goals to be solved by packagers:
1. Provide a default configuration for unexperienced users/admins to have a working system with some services running which also means introducing new config parameters during updates.
And once those inexperienced users are used to things working a certain way, confusing them with no notification is not the right thing to do. Just see the number of questions here and on the forums about this change and how many peoples' systems were thought to have been broken by this update. I know Dominique is reverting this change, but that's not the point. The point is that we shouldn't be changing peoples' configurations without their consent unless there's a VERY GOOD reason (ie, a CVE issue that's being addressed), and then we should let them know on their systems when those updates are applied what the changes are. Trust that the user likely knows what they're doing and has either specifically configured the system to work in a specific way using the config files as presented by the system, or that if they don't know what they're doing, they have at least used the default long enough to have gotten used to it, and that a change to that default is going to be disruptive - and it's going to leave a bad taste in the user's mouth because they weren't warned about the change.
2. Keep everything working also after updates for every system on the planet, e.g. by not applying "new" configs.
This should take precedence. Assume the user knows what they're doing.
I presume nobody has a silver bullet to solve this conflict.
It seems really simple to me. Trust the user to know what they're doing. We gave them a presumably "sane" default when they installed, and if we didn't, that's something to fix in a major update and to document very, very clearly. Not to "fix" on the low-down without an on-system notification when we make the change.
When developing Æ-DIR's ansible roles for various the mainstream distros I kept constantly fighting against too much pseudo config management in the distro's packages. But I have to admit that I can somewhat understand why the packagers are adding config stuff to make things work directly.
My solution for critical stuff is
1. to use completely separate config files whereever possible.
2. to install separate systemd service units referencing these separate config files.
3. to use config management so issues can be fixed simply by re-applying the config in a idempotent way.
4. to create custom packages for some rare cases.
As said everything related to login/sudo or anything else needed to run your config management procedures can get tricky. You should have fallback options prepared on your critical systems.
Everyone did, it seems. And of course using su is always an option. But consider that there are people who (for better or worse) will use sudo in automated processes as well - and who won't find out until their systems start failing. We should at least (at the very minimum) do them the courtesy of advertising it on the systems they're using so they know. To have it be a completely silent change in behaviour is just simply unacceptable to me. This really doesn't seem like rocket science to me. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 08.11.22 01:04, Jim Henderson wrote:
Everyone did, it seems. And of course using su is always an option. But consider that there are people who (for better or worse) will use sudo in automated processes as well - and who won't find out until their systems start failing.
I don't think the default configuration allows anything automated without password or such for anyone, so this will not be broken. And the good thing in this case is, that the "old" (now again current...) config needed the root password to become root. So everyone could just use "su" to fix up their systems and nobody got locked out. Wold the change have been the other way round (users password required before, now the root password), then it would have been way more likely to end up locking someone out of his own system
We should at least (at the very minimum) do them the courtesy of advertising it on the systems they're using so they know. To have it be a completely silent change in behaviour is just simply unacceptable to me.
I guess this is more or less universally agreed on ;-) and that's probably the reason why this was reverted quickly. I personally have no special preference: I'm using the "defaults targetpw" on SUSE systems and the "normal" setup on debian systems. But a change like that certainly needs a "loud" announcement :-) Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue, 8 Nov 2022 17:37:59 +0100, Stefan Seyfried wrote:
On 08.11.22 01:04, Jim Henderson wrote:
Everyone did, it seems. And of course using su is always an option. But consider that there are people who (for better or worse) will use sudo in automated processes as well - and who won't find out until their systems start failing.
I don't think the default configuration allows anything automated without password or such for anyone, so this will not be broken.
Well, that's good.
And the good thing in this case is, that the "old" (now again current...) config needed the root password to become root. So everyone could just use "su" to fix up their systems and nobody got locked out.
Yes, but still, messing about with someone's configuration without telling them is just not a good idea.
Wold the change have been the other way round (users password required before, now the root password), then it would have been way more likely to end up locking someone out of his own system
Possibly, but with physical access, there's almost always a way in. But again, if we hold to the principle of not changing a system's behavior post-installation, then we're not going to run that risk at all.
We should at least (at the very minimum) do them the courtesy of advertising it on the systems they're using so they know. To have it be a completely silent change in behaviour is just simply unacceptable to me.
I guess this is more or less universally agreed on ;-) and that's probably the reason why this was reverted quickly.
I personally have no special preference: I'm using the "defaults targetpw" on SUSE systems and the "normal" setup on debian systems. But a change like that certainly needs a "loud" announcement :-)
Yeah, I don't particularly have a preference other than it's my system, it's set up, so leave it alone, and if it must be changed for a really good reason, tell me during the upgrade. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 2022-11-08 20:56, Jim Henderson wrote:
On Tue, 8 Nov 2022 17:37:59 +0100, Stefan Seyfried wrote:
Yeah, I don't particularly have a preference other than it's my system, it's set up, so leave it alone, and if it must be changed for a really good reason, tell me during the upgrade.
You are right, but AFAIK there is no mechanism currently for that telling. Long ago, rpm would email root. And that information is sent after the deed is done. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Tue, 2022-11-08 at 21:22 +0100, Carlos E. R. wrote:
On 2022-11-08 20:56, Jim Henderson wrote:
On Tue, 8 Nov 2022 17:37:59 +0100, Stefan Seyfried wrote:
Yeah, I don't particularly have a preference other than it's my system, it's set up, so leave it alone, and if it must be changed for a really good reason, tell me during the upgrade.
You are right, but AFAIK there is no mechanism currently for that telling. Long ago, rpm would email root. And that information is sent after the deed is done.
-- Cheers / Saludos,
Carlos E. R. (from 15.3 x86_64 at Telcontar)
zypper (or something adjacent to it) can inform a user of changes as part of a "zypper dup"; mutt was doing it for a while when something changed in the last 1-3 months. -- ~ Scott Bradnick |- Windows Subsystem for Linux (WSL) Developer |-- Tumbleweed: |--- Dell Precision 5540 [NVIDIA Quadro T1000] (x86_64) |--- O-DROID H2+ [UHD Graphics 600] (x86_64) |--- IceWhale ZimaBoard 832 [Intel HD Graphics 500] (x86_64) |--- 2x Raspberry Pi 4 Model B Rev 1.2 (aarch64) |--- 1x Raspberry Pi 3 Model B Rev 1.2 (aarch64) |--- WinBook TW100 (x86_64) https://keys.openpgp.org/ :: DBC5AA9A2D2BAEBC
On Tue, 8 Nov 2022 21:22:54 +0100, Carlos E. R. wrote:
On 2022-11-08 20:56, Jim Henderson wrote:
On Tue, 8 Nov 2022 17:37:59 +0100, Stefan Seyfried wrote:
Yeah, I don't particularly have a preference other than it's my system, it's set up, so leave it alone, and if it must be changed for a really good reason, tell me during the upgrade.
You are right, but AFAIK there is no mechanism currently for that telling. Long ago, rpm would email root. And that information is sent after the deed is done.
IIRC, there's a way for zypper to display information at installation time. And if there isn't at upgrade, then that needs to be addressed, because changing users' system configurations in ways that they're not expecting is just not an acceptable practice. I've worked with software companies for a number of years now, and it is best practice with a configured system that any upgrade to the system preserves the existing behavior regardless of what a new configuration default might be. Don't break peoples' systems by changing configurations on them unless it is absolutely necessary, and if it's absolutely necessary, tell them so they are able to plan *before* their upgrade (or at least abort an upgrade before it starts so they can decide if they're going to do it now or later when they're able to address any fallout from the changes). If we can't do that, then shame on us for not making that possible - and since it's open source, someone should create a defect for it (because let's face it, if we're changing system configuration items on users and not telling them, that is "defective by design"), and then it should be fixed as a high-priority issue. There is NEVER a good reason to silently break a user's configuration. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Hi Jim, You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move. And anyone can help out with that, folks. Don't be shy! Regards, Luciano [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118
On 2022/11/08 05:35:14 -0000, Luciano Santos wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
And anyone can help out with that, folks. Don't be shy!
Regards, Luciano
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118
Add this one to the list https://bugzilla.opensuse.org/show_bug.cgi?id=1205169 "With sudo the XDG variables point to SUDO_UID aka calling user instead of 0 aka root" which e.g. breaks usage of tools with e.g. dbus interface like the gtk version of emacs. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On Tue, Nov 8, 2022 at 8:35 AM Luciano Santos <luc14n0@opensuse.org> wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1],
Which has absolutely nothing to do with this problem. A lot of users did not ever touch /etc/sudoers so replacing old /usr/etc/sudoers with new /usr/etc/sudoers would result in exactly the same issue. And for users who *did* touch /etc/sudoers or otherwise added suitable manual configuration there were no problems without any /usr/etc. The most clean solution on SUSE would be 1. move targetpw to separate sudoers.d snippet 2. move it into a separate package like sudoers-legacy (or whatever, sudo-branding-SUSE if you like) 3. add split-alias to this new package 4. *now* replace default sudoers with whatever content is deemed appropriate so on update users will get new sudoers and sudoers-legacy and on new installation only new sudoers. Whether sudoers and sudoers.d are in /etc or in /usr/etc does not matter for this particular case.
On 11/8/22 09:48, Andrei Borzenkov wrote:
On Tue, Nov 8, 2022 at 8:35 AM Luciano Santos <luc14n0@opensuse.org> wrote:
You're basically describing the /etc move to /usr/etc [1],
Which has absolutely nothing to do with this problem. A lot of users did not ever touch /etc/sudoers so replacing old /usr/etc/sudoers with new /usr/etc/sudoers would result in exactly the same issue.
Full ack. Ciao, Michael.
Andrei Borzenkov wrote: > On Tue, Nov 8, 2022 at 8:35 AM Luciano Santos luc14n0@opensuse.org wrote: > > Hi Jim, > > You're basically describing the /etc move to /usr/etc [1], > > Which has absolutely nothing to do with this problem. A lot of users > did not ever touch /etc/sudoers so replacing old /usr/etc/sudoers with > new /usr/etc/sudoers would result in exactly the same issue. And for > users who *did* touch /etc/sudoers or otherwise added suitable manual > configuration there were no problems without any /usr/etc. > The most clean solution on SUSE would be > 1. move targetpw to separate sudoers.d snippet > 2. move it into a separate package like sudoers-legacy (or whatever, > sudo-branding-SUSE if you like) > 3. add split-alias to this new package > 4. *now* replace default sudoers with whatever content is deemed appropriate > so on update users will get new sudoers and sudoers-legacy and on new > installation only new sudoers. > Whether sudoers and sudoers.d are in /etc or in /usr/etc does not > matter for this particular case. My bad Andrei, I didn't quote the reply from Jim I was replying to, so my answer got a bit out of context. On a side note, I agree with you, even if we were using /usr/etc this issue would've had happened if the user hadn't changed anything sudoers-related, because a bad implementation still is a bad implementation. That change made to SUDO took more than one turn to the wrong direction sadly.
Am 08.11.22 um 09:48 schrieb Andrei Borzenkov:
On Tue, Nov 8, 2022 at 8:35 AM Luciano Santos <luc14n0@opensuse.org> wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1],
Which has absolutely nothing to do with this problem. A lot of users did not ever touch /etc/sudoers so replacing old /usr/etc/sudoers with new /usr/etc/sudoers would result in exactly the same issue. And for users who *did* touch /etc/sudoers or otherwise added suitable manual configuration there were no problems without any /usr/etc.
It's not directly related, but I think it's required to do this properly.
The most clean solution on SUSE would be
1. move targetpw to separate sudoers.d snippet 2. move it into a separate package like sudoers-legacy (or whatever, sudo-branding-SUSE if you like) 3. add split-alias to this new package
The problem here is that the new package is only installed if the existing package has the file mentioned in the split alias. So perhaps we could introduce the snippet, then wait a while, then do the split. But this will only lower the probability of someone skipping doing both updates at once, and we know that some users update rarely. The other problem is that the snippet would also apply to people who don't want targetpw and have changed the default previously.
Whether sudoers and sudoers.d are in /etc or in /usr/etc does not matter for this particular case.
And this is where /usr/etc comes in. We can only split off targetpw in a separate snippet if we know that the existing configuration already has it, and that requires the existing configuration to be the distro default in /usr/etc. Once we have the configuration in /usr/etc (say with targetpw), then we can split into a separate file without changing anything (user changes in /etc would apply on top regardless), then do the package split and suggest to remove the package. (Which would then change settings, but as a conscious choice.) So I don't think we can solve this without moving to /usr/etc first. Aaron
On Tue, 08 Nov 2022 05:35:14 -0000, Luciano Santos wrote:
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
Perhaps, but my preference is that we simply don't change someone's functioning configuration without their consent. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Jim Henderson wrote:
On Tue, 08 Nov 2022 05:35:14 -0000, Luciano Santos wrote:
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move. Perhaps, but my preference is that we simply don't change someone's functioning configuration without their consent. :)
I'd argue that that's everybody preference. But at the end of the day we're still humans, and humans make mistakes. And some mistakes cost more dearly than others.
On Tue, 08 Nov 2022 21:54:41 -0000, Luciano Santos wrote:
Jim Henderson wrote:
On Tue, 08 Nov 2022 05:35:14 -0000, Luciano Santos wrote:
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move. Perhaps, but my preference is that we simply don't change someone's functioning configuration without their consent. :)
I'd argue that that's everybody preference. But at the end of the day we're still humans, and humans make mistakes. And some mistakes cost more dearly than others.
Totally agree. Let's learn from our mistake here and not make it again. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
I had not heard of the move to /usr/etc efforts but when looked into it I found this https://github.com/thkukuk/atomic-updates_and_etc But it seems like it has stalled since 2019 which I guess is why you said it needs all the help it can get. Kind of reminds me of the usr-merge efforts which also stalled for so many years and then finally were completed. Seems like a great idea, since default configs currently can be found in different locations for different packages. Would be great to see some consistency in this area. On 11/8/22 00:35, Luciano Santos wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
And anyone can help out with that, folks. Don't be shy!
Regards, Luciano
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118
-- Regards, Joe
On Sun, Nov 13, jmscdba@gmail.com wrote:
I had not heard of the move to /usr/etc efforts but when looked into it I found this
https://github.com/thkukuk/atomic-updates_and_etc
But it seems like it has stalled since 2019 which I guess is why you said it needs all the help it can get.
If think it has stalled since the document didn't got updated: it didn't got updated since there is nothing to update :) The idea and the arguments haven't changed since then. The /usr/etc move (or /usr/lib, /usr/share, ..., depending on what upstream decides) is still moving forward. Yes, it's slow as in contrast to usr-merge there is not one solution fit's all, but every package needs it's own solution, but it is still moving. Slowly, but continuous. Currently we implement solutions for /etc/shells. Which requires adjustements in many packages... And meanwhile this idea behind /usr/etc is also required for https://uapi-group.org/ You cannot update config files in /etc if you do an image based update. So you need this split.
Kind of reminds me of the usr-merge efforts which also stalled for so many years and then finally were completed.
Seems like a great idea, since default configs currently can be found in different locations for different packages.
Would be great to see some consistency in this area.
Consistency is not possible, nearly every package has a different confguration file format, handling and requirements. If this would not be the case, we would have finished this already 2 years ago... Thorsten
On 11/8/22 00:35, Luciano Santos wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
And anyone can help out with that, folks. Don't be shy!
Regards, Luciano
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118
-- Regards,
Joe
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Hi. Sudo maintainer here. Bsc#1205118, "Move sudo config files to /usr/etc", appeared in my queue last week, and I have started working on it. However, this is my first time working with the switch over to /usr/etc/ so some help would be greatly appreciated. In anticipation of a volunteer, I offer this summary: 1. My work can be seen here: https://build.opensuse.org/package/show/home:jsikes:branches:bsc1205118/sudo 2. Sudo has only one configuration file: "sudoers". Its location is determined during the "%configuration" step. The sudo binary does not support two sudoers files nor having a sudoers file in an alternate or fallback location. However, within the sudoers file we can have any number of "@includedir" directives. There is already one present which now points to "/usr/etc/sudoers.d/". This will enable package maintainers to add sudoers snippets to /usr/etc/sudoers.d/". I have also added an "@includedir" directive enabling system administrators to add snippets to "/etc/sudoers.d/". 3. Sudo includes the utility "visudo" which calls up an editor to modify sudoers. Editing without visudo is discouraged. Should we disable visudo? --Jason On 11/13/22 13:25, Thorsten Kukuk wrote:
On Sun, Nov 13, jmscdba@gmail.com wrote:
I had not heard of the move to /usr/etc efforts but when looked into it I found this
https://github.com/thkukuk/atomic-updates_and_etc
But it seems like it has stalled since 2019 which I guess is why you said it needs all the help it can get. If think it has stalled since the document didn't got updated: it didn't got updated since there is nothing to update :) The idea and the arguments haven't changed since then.
The /usr/etc move (or /usr/lib, /usr/share, ..., depending on what upstream decides) is still moving forward. Yes, it's slow as in contrast to usr-merge there is not one solution fit's all, but every package needs it's own solution, but it is still moving. Slowly, but continuous.
Currently we implement solutions for /etc/shells. Which requires adjustements in many packages...
And meanwhile this idea behind /usr/etc is also required for https://uapi-group.org/ You cannot update config files in /etc if you do an image based update. So you need this split.
Kind of reminds me of the usr-merge efforts which also stalled for so many years and then finally were completed.
Seems like a great idea, since default configs currently can be found in different locations for different packages.
Would be great to see some consistency in this area. Consistency is not possible, nearly every package has a different confguration file format, handling and requirements. If this would not be the case, we would have finished this already 2 years ago...
Thorsten
On 11/8/22 00:35, Luciano Santos wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
And anyone can help out with that, folks. Don't be shy!
Regards, Luciano
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118 -- Regards,
Joe
Hi Jason, Great to see you here :) On Mon, 2022-11-14 at 15:17 -0800, Jason Sikes wrote:
2. Sudo has only one configuration file: "sudoers". Its location is determined during the "%configuration" step. The sudo binary does not support two sudoers files nor having a sudoers file in an alternate or fallback location.
That's unfortunate, and exactly the sort of problem Thorsten was referencing when saying sometimes major engineering needs to take place. In an ideal world, we really need the following /usr/etc/sudoers - the packaged default config file /usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file /etc/sudoers.d - user provided snippits In that same ideal world, the configurations would be applied in that order, with the lowest in the list overriding/taking precidence over the top of the list. I suppose what we could do (though ugly) is something like this /usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file, defined in the %configuration step just like now but SYMLIKKED to a file /usr/etc/sudoers /etc/sudoers.d - user provided snippits This would mean we'd have a nice read-only sudoers in /usr/etc, but it would be read from /etc and a user could just replace the symlink with their own config if they felt like it. Then, given visudo is the recommended way of modifying the sudoers..could visudo detect if /etc/sudoers is a symlink? Then could it drop the symlink, copy /usr/etc/sudoers to /etc/sudoers, and open /etc/sudoers for editing? Normally I wouldn't go down this road, but given visudo is recommended for editing anyway, I guess we can move problem of handling /usr/etc/sudoers and /etc/sudoers gracefully into that Just a thought -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 2022-11-15 10:32, Richard Brown wrote:
Hi Jason,
Great to see you here :)
On Mon, 2022-11-14 at 15:17 -0800, Jason Sikes wrote:
2. Sudo has only one configuration file: "sudoers". Its location is determined during the "%configuration" step. The sudo binary does not support two sudoers files nor having a sudoers file in an alternate or fallback location.
That's unfortunate, and exactly the sort of problem Thorsten was referencing when saying sometimes major engineering needs to take place.
In an ideal world, we really need the following
/usr/etc/sudoers - the packaged default config file /usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file /etc/sudoers.d - user provided snippits
In that same ideal world, the configurations would be applied in that order, with the lowest in the list overriding/taking precidence over the top of the list.
Can you really, at the packaging end, really do all that? Shouldn't this be done upstream? ...
Then, given visudo is the recommended way of modifying the sudoers..could visudo detect if /etc/sudoers is a symlink?
Consider that visudo is currently designed to be able to call any editor the admin wishes. Not only "vi". Consider that visudo should check all the files and present a single edit view Again, can you really, at the packaging end, really do all that? Shouldn't this be done upstream? IMHO, doing it here may result in a hack. Just another thought :-) -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Thorsten Kukuk <kukuk@suse.de> wrote:
/usr on a separate partition or subvolume will become the new default for most/nearly all Linux distributions in the next years. That's a hard requirement for many (security) concepts.
I remember back in the late 90s that /usr was supposed to be read-only and that Solaris did that. Linux didn’t because it was more of a hobby at the time. (Please don’t hurt me for saying that.) Richard Brown <rbrown@suse.de> wrote:
Hi Jason,
Great to see you here 😄
:D Thank you!
I suppose what we could do (though ugly) is something like this
/usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file, defined in the %configuration step just like now but SYMLIKKED to a file /usr/etc/sudoers /etc/sudoers.d - user provided snippits
This would mean we'd have a nice read-only sudoers in /usr/etc, but it would be read from /etc and a user could just replace the symlink with their own config if they felt like it.
Then, given visudo is the recommended way of modifying the sudoers..could visudo detect if /etc/sudoers is a symlink?
Then could it drop the symlink, copy /usr/etc/sudoers to /etc/sudoers, and open /etc/sudoers for editing?
I just tested it out. Visudo appears to behave the way we want! germ117:/ # ls -l /etc/sudoers -r--r----- 1 root root 3041 Nov 15 00:38 /etc/sudoers germ117:/ # mv /etc/sudoers /usr/etc/sudoers germ117:/ # ln -s /usr/etc/sudoers /etc/sudoers germ117:/ # ls -l /etc/sudoers lrwxrwxrwx 1 root root 16 Nov 17 03:07 /etc/sudoers -> /usr/etc/sudoers germ117:/ # visudo germ117:/ # ls -l /etc/sudoers -r--r----- 1 root root 3043 Nov 17 03:09 /etc/sudoers germ117:/ # ls -l /usr/etc/sudoers -r--r----- 1 root root 3041 Nov 15 00:38 /usr/etc/sudoers Carlos E. R. <carlos.e.r@opensuse.org> wrote:
Consider that visudo should check all the files and present a single edit view
Can you really, at the packaging end, really do all that? Shouldn't
Sort of. Visudo presents only one file. The “@includedir” is down at the bottom of that file. this be done > upstream? I agree. This is definitely a job for upstream. I just took a look at the code, and I see I can help, if upstream wishes.
On 11/15/22 01:32, Richard Brown wrote:
I suppose what we could do (though ugly) is something like this
/usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file, defined in the %configuration step just like now but SYMLIKKED to a file /usr/etc/sudoers /etc/sudoers.d - user provided snippits
This would mean we'd have a nice read-only sudoers in /usr/etc, but it would be read from /etc and a user could just replace the symlink with their own config if they felt like it.
I did just that just now as a proof-of-concept, and it seems to work! https://build.opensuse.org/package/revisions/home:jsikes:branches:bsc1205118... I tested it out just now, and visudo seems to magically do what we want. Of course, it would be better if sudo would work the way we really want without using this symlink hack, but we have this. I'm still looking at how we can get sudo to check multiple sudoers files. --Jason
Update on sudo-hacking. Sudo now checks for configuration files in any number of locations, determined by the ./configure parameter "sysconfdir". Currently, I have it configured thus: |%if %{defined _distconfdir}|| || --sysconfdir="/etc /usr/etc" \|| ||%endif| In this case, sudo first looks for configuration files in '/etc' and then '/usr/etc'. (Three or more locations are possible but likely not practical.) I have tested it out, and It works at least for the sudoers file. So, yay! No symlinks! Caveats: * The functions I added to sudo are duplicated; I added identical code to two places. I still need to fix that. * This is my first time hacking Makefiles. Configure seems to expect "sysconfdir" to contain only one path. I'm not sure if there is a standard for something like this. * Error messages might be confusing. Documentation will also need lots of work. * I don't know how to get the changes to apply within the sudoers file. The last line of sudoers points to the sudoers.d directory. I had to hardcode the directory instead of using some variation of "@sysconfdir@" like I was able to in the Makefiles. --Jason On 11/21/22 18:00, Jason Sikes wrote:
On 11/15/22 01:32, Richard Brown wrote:
I suppose what we could do (though ugly) is something like this
/usr/etc/sudoers.d - packaged snippits /etc/sudoers - the user provided config file, defined in the %configuration step just like now but SYMLIKKED to a file /usr/etc/sudoers /etc/sudoers.d - user provided snippits
This would mean we'd have a nice read-only sudoers in /usr/etc, but it would be read from /etc and a user could just replace the symlink with their own config if they felt like it.
I did just that just now as a proof-of-concept, and it seems to work!
https://build.opensuse.org/package/revisions/home:jsikes:branches:bsc1205118...
I tested it out just now, and visudo seems to magically do what we want.
Of course, it would be better if sudo would work the way we really want without using this symlink hack, but we have this.
I'm still looking at how we can get sudo to check multiple sudoers files.
--Jason
G'day Tumblers, I really am getting old. It kind of crept up on me. I was young and carefree once. I had long hair and drove a Mazda RX4. When I wondered about something to do with my Mazda, I looked for stuff that Felix Miata wrote because he was the guru. I guess that some things change, and some stay the same. The "sudo debate" really has not changed much. There are other ways of executing commands as root (or another user) that come with TW by default on a normal desktop install. I can't find any that have a config in /usr/etc/, and all of them ask for the "root" password. machinectl and systemd-run (part of systemd) seem to ask for the root password by default, and they are marvellously difficult to configure. Knowing where the config really lives is not important since it would cause my brain to implode before I could configure it. Although "machinectl shell .host" does not pass the exit code of whatever you are running, "systemd-run --pty" does, and so it can even be used sort of in a script (with enough effort). There is also pkexec, which is part of polkit. This works fine in a script. The configuration files for this seem to be in /etc/polkit-1/ on my install. I can't see anything overriding this in /usr/etc/. Nobody in the real world configures this. It is configured with XML and JavaScript-like ".rules" files like the rest of polkit. It asks for root by default. There is "su -c", and that uses pam configuration which by default asks for the target password (root in this case). The configuration file is /etc/pam.d/su (which does not exist in my install). Then there is, of course, sudo. It now asks for a user password by default. Some other distros do that. I don't like the change to the defaults because on a single user system, having that extra "root" password is great because it should be different to the user password. Also, on a multi-user sytsem, hopefully he sysadmin knows how to configure sudo and actively changed it anyway. But... it doesn't affect me because I have changed the defaults. Let's leave it because I am OK. But what about those other ones!? What happens if they get popular!? Should we also change the configuration for polkit's "pkexec" to prompt for a user password instead? is anyone that excited by XML? What about systemd-run and machinectl!? Do we play with the pam config for su? And now we go with moving the configuration to /usr/etc/ Without changing code, sudo et al looks for /etc/sudo.conf for sudo configuration. This does not have an include command, so /etc/ and only /etc/ it is. The sudoers file DOES (now) have an include statement though. My take on it, if we REALLY want to get into the whole "/usr/ the new /" trend, would be: Put an @include in /etc/sudoers to include /usr/etc/sudoers Put an @includedir in /usr/etc/sudoers to include /usr/etc/sudoers.d Symlink /usr/etc/sudoers.d to /etc/sudoers.d/ Make visudo edit /usr/etc/sudoers by using "Plugin sudoers_policy sudoers.so sudoers_file=/usr/etc/sudoers" in /usr/etc/sudo.conf Symlink /usr/etc/sudo.conf to /etc/sudo.conf Maybe it is because I am getting old, but I see this /usr/etc trend as one big solution without a problem, and it creates its own problems. Don't get me started on snaps/flatpacks/containers-for-the-sake-of-it etc. We already have /etc/default (which contains /etc/default/su which is a symlink to /usr/etc/default/su which overrides configuration instead of providing defaults) and that confuses me enough. Are we heading towards a point where, like with /bin/ and /sbin/, /etc/ is just a symlink or bind-mount to /usr/etc/? If we get to /etc/ being a symlink of /usr/etc/ then I feel that is better. I hate complexity unless it is really needed. Does anyone use a separate /usr/ that is not a subvolume with TW (if they do, they loose /sbin/ on a failed /usr/ mount anyway)? -- Ben On 14/11/22 07:25, Thorsten Kukuk wrote:
CAUTION: This email originated from outside of Interactive. Do not click links or open attachments unless you recognise the sender and know the content is safe.
On Sun, Nov 13, jmscdba@gmail.com wrote:
I had not heard of the move to /usr/etc efforts but when looked into it I found this
https://github.com/thkukuk/atomic-updates_and_etc <https://protect-au.mimecast.com/s/yjklC2xMqmcVmojgc9KbdX?domain=github.com>
But it seems like it has stalled since 2019 which I guess is why you said it needs all the help it can get.
If think it has stalled since the document didn't got updated: it didn't got updated since there is nothing to update :) The idea and the arguments haven't changed since then.
The /usr/etc move (or /usr/lib, /usr/share, ..., depending on what upstream decides) is still moving forward. Yes, it's slow as in contrast to usr-merge there is not one solution fit's all, but every package needs it's own solution, but it is still moving. Slowly, but continuous.
Currently we implement solutions for /etc/shells. Which requires adjustements in many packages...
And meanwhile this idea behind /usr/etc is also required for https://uapi-group.org/ <https://protect-au.mimecast.com/s/iGfdC3QNrnuX4YBOhvzIyM?domain=uapi-group.org> You cannot update config files in /etc if you do an image based update. So you need this split.
Does any of this matter for TW? Is this more for microserver distros?
Kind of reminds me of the usr-merge efforts which also stalled for so many years and then finally were completed.
Seems like a great idea, since default configs currently can be found in different locations for different packages.
Would be great to see some consistency in this area.
Consistency is not possible, nearly every package has a different confguration file format, handling and requirements. If this would not be the case, we would have finished this already 2 years ago...
Thorsten
On 11/8/22 00:35, Luciano Santos wrote:
Hi Jim,
You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move.
And anyone can help out with that, folks. Don't be shy!
Regards, Luciano
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 <https://protect-au.mimecast.com/s/GM9mC4QOvouz8Aoqiji7tg?domain=bugzilla.opensuse.org> [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118 <https://protect-au.mimecast.com/s/ysyQC5QPwpuMlYv2hl_7sV?domain=bugzilla.opensuse.org>
-- Regards,
Joe
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Tue, Nov 15, Ben Holmes wrote:
There are other ways of executing commands as root (or another user) that come with TW by default on a normal desktop install. I can't find any that have a config in /usr/etc/, and all of them ask for the "root" password.
Correct, they have the configs in /usr/lib/..., /usr/share/... or something similar.
There is "su -c", and that uses pam configuration which by default asks for the target password (root in this case). The configuration file is /etc/pam.d/su (which does not exist in my install).
/etc/pam.d/su is for admin changed configuration files, /usr/lib/pam.d/su is the one provided by the distribution. Linux-PAM had this since ages, except that no distribution adjusted their packaging.
And now we go with moving the configuration to /usr/etc/
No. We split the configuration: /usr contains the distribution defaults, /etc will contain the host specific config or changes.
Maybe it is because I am getting old, but I see this /usr/etc trend as one big solution without a problem, and it creates its own problems.
That's because you are most likely a Desktop user and you are not using fancy things like atomic updates/transactional updates, or image based updates, embedded systems, ... Linux distributions out there in the world are used for much, much more than only Desktop, and most of this usecases have different requirements than a Desktop. But even for you as Desktop user this has big advantages: default config settings can much easier be updated without breaking modified configurations. I suggest to take a deeper look at https://www.uapi-group.org.
Don't get me started on snaps/flatpacks/containers-for-the-sake-of-it etc. We already have / etc/default (which contains /etc/default/su which is a symlink to /usr/etc/ default/su which overrides configuration instead of providing defaults) and that confuses me enough.
/etc/default/su should never be a symlink to /usr/etc/default/su, did you create that yourself?
Are we heading towards a point where, like with /bin/ and /sbin/, /etc/ is just a symlink or bind-mount to /usr/etc/?
No. /etc will contain host specific configurations and admin made changes, and will stay writeable for that reason.
If we get to /etc/ being a symlink of /usr/etc/ then I feel that is better. I hate complexity unless it is really needed.
/etc being a symlink to /usr/etc doesn't make any sense and doesn't solve any problems. Beside that this will not work, since /usr/etc will be read-only in most scenarios.
Does anyone use a separate /usr/ that is not a subvolume with TW (if they do, they loose /sbin/ on a failed /usr/ mount anyway)?
/usr on a separate partition or subvolume will become the new default for most/nearly all Linux distributions in the next years. That's a hard requirement for many (security) concepts. I have some PoC machines with this setup, works fine. Except that still RPMs try to install outside of /usr, which with an image based approach does not work. Thorsten
-- Ben
On 14/11/22 07:25, Thorsten Kukuk wrote:
CAUTION: This email originated from outside of Interactive. Do not click links or open attachments unless you recognise the sender and know the content is safe.
On Sun, Nov 13, jmscdba@gmail.com wrote:
> I had not heard of the move to /usr/etc efforts but when looked into it I > found this > > https://github.com/thkukuk/atomic-updates_and_etc > > But it seems like it has stalled since 2019 which I guess is why you said it > needs all the help it can get.
If think it has stalled since the document didn't got updated: it didn't got updated since there is nothing to update :) The idea and the arguments haven't changed since then.
The /usr/etc move (or /usr/lib, /usr/share, ..., depending on what upstream decides) is still moving forward. Yes, it's slow as in contrast to usr-merge there is not one solution fit's all, but every package needs it's own solution, but it is still moving. Slowly, but continuous.
Currently we implement solutions for /etc/shells. Which requires adjustements in many packages...
And meanwhile this idea behind /usr/etc is also required for https:// uapi-group.org/ You cannot update config files in /etc if you do an image based update. So you need this split.
Does any of this matter for TW?
Is this more for microserver distros?
> Kind of reminds me of the usr-merge efforts which also stalled for so many > years and then finally were completed. > > Seems like a great idea, since default configs currently can be found in > different locations for different packages. > > Would be great to see some consistency in this area.
Consistency is not possible, nearly every package has a different confguration file format, handling and requirements. If this would not be the case, we would have finished this already 2 years ago...
Thorsten
> On 11/8/22 00:35, Luciano Santos wrote: > > Hi Jim, > > > > You're basically describing the /etc move to /usr/etc [1], an ongoing effort that needs all the help it can get. A specific bug for SUDO [2] has already been filed. So, if it's feasible, someone will eventually make that move. > > > > And anyone can help out with that, folks. Don't be shy! > > > > Regards, > > Luciano > > > > [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 > > [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1205118 > > -- > Regards, > > Joe
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 15/11/22 18:38, Thorsten Kukuk wrote:
On Tue, Nov 15, Ben Holmes wrote:
There are other ways of executing commands as root (or another user) that come with TW by default on a normal desktop install. I can't find any that have a config in /usr/etc/, and all of them ask for the "root" password.
Correct, they have the configs in /usr/lib/..., /usr/share/... or something similar.
There is "su -c", and that uses pam configuration which by default asks for the target password (root in this case). The configuration file is /etc/pam.d/su (which does not exist in my install).
/etc/pam.d/su is for admin changed configuration files, /usr/lib/pam.d/su is the one provided by the distribution. Linux-PAM had this since ages, except that no distribution adjusted their packaging.
Thanks for the information there. I must admit, I didn't know that. I have never seen it on anything I have every used.
And now we go with moving the configuration to /usr/etc/
No. We split the configuration: /usr contains the distribution defaults, /etc will contain the host specific config or changes.
I thought that is what /etc/defaults was originally for. Can that be symlinked to the (R/O on some systems by design) /usr/etc filesystem. They seem to perform some pretty similar things. Does the added complexity give us anything?
Maybe it is because I am getting old, but I see this /usr/etc trend as one big solution without a problem, and it creates its own problems.
That's because you are most likely a Desktop user and you are not using fancy things like atomic updates/transactional updates, or image based updates, embedded systems, ... Linux distributions out there in the world are used for much, much more than only Desktop, and most of this usecases have different requirements than a Desktop.
I figured TW is typically aimed at desktop users. I have a couple of Leap instances on servers, but most things are, due to policy, RHEL. I completely understand the use case for micro/core OS systems, such as container platforms and KVM nodes. It even makes sense for some general purpose servers. I am more of an embedded guy myself, and standards are less... enforced... in that world. But maybe that attitude needs to change fast (considering the holes in IOT etc).
But even for you as Desktop user this has big advantages: default config settings can much easier be updated without breaking modified configurations.
I suggest to take a deeper look at https://www.uapi-group.org <https://protect-au.mimecast.com/s/0zrPCvl1xBuElVzOT5ck3h?domain=uapi-group.org>.
That is one fun read. I am not sure about partition type 0xEA.. but otherwise, it seems to be OK as a standard.
Don't get me started on snaps/flatpacks/containers-for-the-sake-of-it etc. We already have / etc/default (which contains /etc/default/su which is a symlink to /usr/etc/ default/su which overrides configuration instead of providing defaults) and that confuses me enough.
/etc/default/su should never be a symlink to /usr/etc/default/su, did you create that yourself?
Nope. It is not part of any package I have installed though, so I am not sure how it got there. I assumed. Due to its location, this file should contain default settings (not something that overrides settings as it states in the file, but something over which settings are overridden), and since /usr/etc also holds default settings, I am not worried about it. I wonder if an old package did this. I have been updating this same install for 4 years now on this laptop. I haven't checked any other systems to see if it is there.
Are we heading towards a point where, like with /bin/ and /sbin/, /etc/ is just a symlink or bind-mount to /usr/etc/?
No. /etc will contain host specific configurations and admin made changes, and will stay writeable for that reason.
Makes sense.
If we get to /etc/ being a symlink of /usr/etc/ then I feel that is better. I hate complexity unless it is really needed.
/etc being a symlink to /usr/etc doesn't make any sense and doesn't solve any problems. Beside that this will not work, since /usr/etc will be read-only in most scenarios.
Fair call if we want to follow that particular standard.
Does anyone use a separate /usr/ that is not a subvolume with TW (if they do, they loose /sbin/ on a failed /usr/ mount anyway)?
/usr on a separate partition or subvolume will become the new default for most/nearly all Linux distributions in the next years. That's a hard requirement for many (security) concepts. I have some PoC machines with this setup, works fine. Except that still RPMs try to install outside of /usr, which with an image based approach does not work.
Thorsten
The read-only USR is not something I support for a desktop, and unless it is read-only, it carries the same risk (even if it is on another LUN). If you have root, you can probably just remount (unless /usr is on squash or ISO9660 or some other read-only FS), and if you do not, then permissions (and things like SELinux/Apparmor) should stop issues. Once again, this is great on a transactional/atomic update system, and I am OK with my servers doing that, but it just makes my desktop feel more restricted. TW is used on many desktops, so I hope that never gets enforced. Without a read-only /usr, putting 'vendor' defaults in one place (/etc/defaults or /usr/etc.. either way is OK) does have the benefit of less "rpmsave" files floating around, so now I know what it is, it seems like a good idea. Thanks for the information Thorsten, it was very enlightening. I feel younger :) -- Ben
On Thu, Nov 17, Ben Holmes wrote:
On 15/11/22 18:38, Thorsten Kukuk wrote:
We split the configuration: /usr contains the distribution defaults, /etc will contain the host specific config or changes.
I thought that is what /etc/defaults was originally for.
"/etc/default" is Debians answer to /etc/sysconfig from RedHat and us. Containing configuration variables for init scripts or today systemd services. Both locations are not standarized and randomly used today. But they were never to intendent to overwrite distribution defaults. Only look at your system, for most config files there is nothing in /etc/defaults or /etc/sysconfig, which would allow to overwrite values. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Am Donnerstag, 17. November 2022, 08:54:06 CET schrieb Thorsten Kukuk:
Both locations are not standarized and randomly used today.
Thorsten, you know such a lot of facts of the whereabouts of the root tree. Now, that you've taken the time and effort to write it down here in various emails, maybe you can copy-paste it into an openSUSE wiki somewhere? Starting with /etc? -- Regards, Alexander
On Thu, Nov 17, AW wrote:
Am Donnerstag, 17. November 2022, 08:54:06 CET schrieb Thorsten Kukuk:
Both locations are not standarized and randomly used today.
Thorsten, you know such a lot of facts of the whereabouts of the root tree. Now, that you've taken the time and effort to write it down here in various emails, maybe you can copy-paste it into an openSUSE wiki somewhere? Starting with /etc?
The good think on public informations and a wiki is: everybody can do that ;) Sorry, but most what I wrote is already part of FHS, various wiki pages on opensuse.org and similar pages. The big problem with creating such a wiki page is, that it is very fast outdated, since nobody really updates it afterwards. If somebody has the time and is willing to maintain such a wiki, fine. But I don't have the time. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Thorsten Kukuk wrote:
On Mon, Nov 07, Vojtěch Zeisek wrote:
Dne pondělí 7. listopadu 2022 9:41:57 CET, Dominique Leuenberger / DimStar napsal(a):
Background situation: a user requested the sudo configuration to be changed to no longer ask for the 'target user's password', but rather ask for the user willing to become somebody else's password (as other distros do) As this change is definitively bad in its current form I have reverted the sudo package to the state it was before snapshot 1103 and published the same version into the openSUSE Tumbleweed update channel.
What's really rotten here is the process. Some FUD was entered into a (non public?) Jira ticket, then referenced in a random bug report. Based on that a security sensitive, invasive distro wide change was implemented without involving anyone who has the side effects for the distro as a whole in mind, nor the ones originally implementing the current behavior. Now we additionally have a discussion on the Factory list here. Where would someone bring up arguments? copy&paste in all three places?
If the original motivation was to align with other distros, if I get it correctly, now we are just reverting back to openSUSE default, so different state than other distros; so will there be any change towards "general consensus", ideally with some automated migration? I added myself into "wheel" group and uncommented in /etc/sudoers "%wheel ALL=(ALL:ALL) ALL", which is fine, but of course in case of automated migration I wouldn't even notice change. :-)
The motiviation was not to align with other distros, but to fix the usage of sudo as it as designed. openSUSE is using sudo as "modern implementation of su" instead of "sudo". With the current setup, you can replace sudo with su in most cases. The motivation was to configure sudo to work as it was designed for and for security reasons. And mid- to longterm, we need to find a way to change the defaults for sudo to match peoples expectation.
What are people's expectations and what is sudo designed for exactly? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
What are people's expectations and what is sudo designed for exactly?
Sudo is designed to let user A execute commands as user B, without having to know the password of user B. And this is exactly what "Defaults targetpw" breaks, but what anyone who deals with other UNIX variants (not just linux, but UNIX) would know and expect. I actually remember that "Defaults targetpw" was actually introduced at some point after suse had been following the design principle of sudo for years, and I remember how I was surprised by that - because it basically turns sudo into a glorified su. In actual fact, with "Defaults targetpw" there is not even any NEED to have sudo at all - just use su and be done with it. I *do* agree with the general feeling of "this could have been handled better", tho. I think somewhere in this thread there was a suggestion of putting the "Default targetpw" in a config snippet in /etc/sudoers.d and packaging it as a subpackage - that would be pretty good. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Tuesday 2022-11-08 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
What are people's expectations and what is sudo designed for exactly?
In actual fact, with "Defaults targetpw" there is not even any NEED to have sudo at all - just use su and be done with it.
"""By default, the sudoers policy caches credentials on a per-terminal basis for 5 minutes.""" Now riddle me this, why that could not have been added to su instead.
On 11/8/22 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
What are people's expectations and what is sudo designed for exactly?
Sudo is designed to let user A execute commands as user B, without having to know the password of user B.
Basically yes. But today sudo has more functionality (e.g. audit logging) which may be also a wanted feature.
I actually remember that "Defaults targetpw" was actually introduced at some point after suse had been following the design principle of sudo for years, and I remember how I was surprised by that - because it basically turns sudo into a glorified su.
Maybe we have to consider two distinct use-cases: 1. An admin maintaining stuff on a server without knowing the password of 'root' or other similar privileged user. By default grant group 'wheel' the right to do this. 2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
I *do* agree with the general feeling of "this could have been handled better", tho. I think somewhere in this thread there was a suggestion of putting the "Default targetpw" in a config snippet in /etc/sudoers.d and packaging it as a subpackage - that would be pretty good.
Sounds good. Maybe two different packages for the above two use-cases? Not sure whether those should be mutually exclusive though. Ciao, Michael.
Am Dienstag, 8. November 2022, 12:49:58 CET schrieb Michael Ströder:
2. An desktop user invoking a setup component which requires more privileges.
Anyone remember the rant by Linus T. about openSUSE? Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on. Regards, Alexander
On 11/8/22 13:36, AW wrote:
Am Dienstag, 8. November 2022, 12:49:58 CET schrieb Michael Ströder:
2. An desktop user invoking a setup component which requires more privileges.
Anyone remember the rant by Linus T. about openSUSE?
Yes, I remember.
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that? Ciao, Michael.
On 2022-11-08 17:46, Michael Ströder wrote:
On 11/8/22 13:36, AW wrote:
...
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that?
Could you expand on this, please? If we can not add the normal user to the wheel group, then what can we do? :-? I have seen comments against wheel for decades, even in documentation, but never an explanation. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Tue, 8 Nov 2022 19:15:23 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-08 17:46, Michael Ströder wrote:
On 11/8/22 13:36, AW wrote:
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that?
Could you expand on this, please?
If we can not add the normal user to the wheel group, then what can we do?
Yes, compare it to the installer giving the option to make the user password the same as root's.
I have seen comments against wheel for decades, even in documentation, but never an explanation.
-- Robert Webb
On 2022-11-08 19:41, Robert Webb wrote:
On Tue, 8 Nov 2022 19:15:23 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-11-08 17:46, Michael Ströder wrote:
On 11/8/22 13:36, AW wrote:
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that?
Could you expand on this, please?
If we can not add the normal user to the wheel group, then what can we do?
Yes, compare it to the installer giving the option to make the user password the same as root's.
Ok, so that is the issue. Anyway, that is the default on openSUSE. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 11/8/22 19:15, Carlos E. R. wrote:
On 2022-11-08 17:46, Michael Ströder wrote:
On 11/8/22 13:36, AW wrote:
...
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that?
Could you expand on this, please?
If some reconfiguration needs broad root access then IMHO the user should know the root password - for now. (Hmm, IIRC the Yast installer already suggests to set a common password for the first end-user and root which is somewhat debatable too.) One could differentiate this policy further for certain commands but this needs proper considerations for various use-cases.
If we can not add the normal user to the wheel group, then what can we do?
A user can be added to the wheel group if root on this system decides to do so. But it should probably not be the default configuration. As said I don't have a silver bullet at hand to solve all possible use-cases with one simple policy change. This needs some collective thoughts.
I have seen comments against wheel for decades, even in documentation, but never an explanation. It really depends on what 'wheel' group members are authorized to do on a particular system. A sudoers entry for broad root access would IMHO be dangerous if normal desktop users are in 'wheel'.
Ciao, Michael.
On 2022-11-08 20:39, Michael Ströder wrote:
On 11/8/22 19:15, Carlos E. R. wrote:
On 2022-11-08 17:46, Michael Ströder wrote:
On 11/8/22 13:36, AW wrote:
...
Scenario: User needs to install new printer without admin-PW. So 'sudo' would become a lesser 'su': Users in the wheel group have some priviledges. Including installing a printer, adding a new wifi network and so on.
For security reasons you don't want to add the normal desktop user to wheel group. Or do you want that?
Could you expand on this, please?
If some reconfiguration needs broad root access then IMHO the user should know the root password - for now. (Hmm, IIRC the Yast installer already suggests to set a common password for the first end-user and root which is somewhat debatable too.)
One could differentiate this policy further for certain commands but this needs proper considerations for various use-cases.
Ok, but this doesn't clash. You can have the normal user added to wheel, and still someone has the root password. In a home setup, it is all one person.
If we can not add the normal user to the wheel group, then what can we do?
A user can be added to the wheel group if root on this system decides to do so. But it should probably not be the default configuration.
As said I don't have a silver bullet at hand to solve all possible use-cases with one simple policy change. This needs some collective thoughts.
Ok, but this doesn't mean that I should not add my user to wheel. Just not the default policy for all openSUSE? Ok, fine. But nothing yet against me doing it for myself in my machines. No security reasons yet.
I have seen comments against wheel for decades, even in documentation, but never an explanation. It really depends on what 'wheel' group members are authorized to do on a particular system. A sudoers entry for broad root access would IMHO be dangerous if normal desktop users are in 'wheel'.
Why? All users? No. But the user who is also the root, why not? I don't see the risk. Unless the risk is that an attacker that gets access as that user also gets root access - but that is the same as root having the same password as the first user, which is the default in openSUSE. So, no new risk, no added risk. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 2022-11-08 12:49, Michael Ströder wrote:
On 11/8/22 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
Maybe we have to consider two distinct use-cases:
1. An admin maintaining stuff on a server without knowing the password of 'root' or other similar privileged user. By default grant group 'wheel' the right to do this.
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that. So people use sudo. We can no longer change this, and working differently is bad for users.
I *do* agree with the general feeling of "this could have been handled better", tho. I think somewhere in this thread there was a suggestion of putting the "Default targetpw" in a config snippet in /etc/sudoers.d and packaging it as a subpackage - that would be pretty good.
Sounds good. Maybe two different packages for the above two use-cases? Not sure whether those should be mutually exclusive though.
AFAIK you just need one package and some additional packages that drop the adequate config files in /etc/sudoers.d/ with different behaviours. Just add some small text in the description of those packages. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Op 08-11-2022 om 14:04 schreef Carlos E. R.:
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that. So people use sudo. We can no longer change this, and working differently is bad for users.
On the desktop it is maybe nice to take into account what the desktop environments assume. In KDE Plasma the user account module in systemsettings has the option to set the type of user to "standard user" or "administrator". The latter adds the user to the group "wheel", which in the default openSUSE config does not do anything. Cor
Am Dienstag, 8. November 2022, 15:00:30 CET schrieb Cor Blom:
Op 08-11-2022 om 14:04 schreef Carlos E. R.:
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that. So people use sudo. We can no longer change this, and working differently is bad for users.
On the desktop it is maybe nice to take into account what the desktop environments assume. In KDE Plasma the user account module in systemsettings has the option to set the type of user to "standard user" or "administrator". The latter adds the user to the group "wheel", which in the default openSUSE config does not do anything.
Cor
This seems important, at least to me (=user). So the wheel group needs the rights to add a new printer (or change printer settings) and add new wifis. -- Regards, Alexander
On 2022-11-09 11:31, AW wrote:
Am Dienstag, 8. November 2022, 15:00:30 CET schrieb Cor Blom:
Op 08-11-2022 om 14:04 schreef Carlos E. R.:
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that. So people use sudo. We can no longer change this, and working differently is bad for users.
On the desktop it is maybe nice to take into account what the desktop environments assume. In KDE Plasma the user account module in systemsettings has the option to set the type of user to "standard user" or "administrator". The latter adds the user to the group "wheel", which in the default openSUSE config does not do anything.
Cor
This seems important, at least to me (=user).
So the wheel group needs the rights to add a new printer (or change printer settings) and add new wifis.
You simply have to edit /etc/sudoers for that: #Defaults targetpw # Ask for the password of the target user #ALL ALL=(ALL:ALL) ALL # WARNING: only use this together with 'Defaults targetpw' ## Uncomment to allow members of group wheel to execute any command %wheel ALL=(ALL:ALL) ALL I hope I got it right, I can not test it. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 11/8/22 14:04, Carlos E. R. wrote:
On 2022-11-08 12:49, Michael Ströder wrote:
On 11/8/22 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
Maybe we have to consider two distinct use-cases:
1. An admin maintaining stuff on a server without knowing the password of 'root' or other similar privileged user. By default grant group 'wheel' the right to do this.
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that.
Just referring to Google foo is not a decent requirements engineering. Whatever solution openSUSE comes up with the above use-cases have to considered more thoroughly.
So people use sudo. We can no longer change this, and working differently is bad for users. This statement is too broad to be useful.
Ciao, Michael.
On 2022-11-08 17:51, Michael Ströder wrote:
On 11/8/22 14:04, Carlos E. R. wrote:
On 2022-11-08 12:49, Michael Ströder wrote:
On 11/8/22 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
Maybe we have to consider two distinct use-cases:
1. An admin maintaining stuff on a server without knowing the password of 'root' or other similar privileged user. By default grant group 'wheel' the right to do this.
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that.
Just referring to Google foo is not a decent requirements engineering.
Whatever solution openSUSE comes up with the above use-cases have to considered more thoroughly.
I'm not referring to Google foo. You misunderstood me. I say that when people google the solution to do _anything_ in Linux and uses google (even help people will tell people now and then to google before asking), they will be told to use sudo. For example, google "howo to mount external disk" the first answer is: <https://www.tomshardware.com/how-to/mount-drives-linux> which says: sudo mkdir /media/pendrive sudo mount /dev/sdb1 /media/pendrive sudo umount /media/pendrive sudo mkdir /media/iso sudo mount -o loop Downloads/fossapup64-9.5.iso /media/iso etc. The same will happen for any question you ask. People will use sudo instead of su with openSUSE because google tells people to use sudo, not su. That's a fact and we can not change it. Even if sudo is not the openSUSE way of doing things. So people need sudo to work, proven by the many people having problems this weekend. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Am 08.11.22 um 19:24 schrieb Carlos E. R.:
On 2022-11-08 17:51, Michael Ströder wrote:
On 11/8/22 14:04, Carlos E. R. wrote:
On 2022-11-08 12:49, Michael Ströder wrote:
On 11/8/22 11:30, Mathias Homann wrote:
Am Dienstag, 8. November 2022, 11:10:29 CET schrieb Ludwig Nussel:
Maybe we have to consider two distinct use-cases:
1. An admin maintaining stuff on a server without knowing the password of 'root' or other similar privileged user. By default grant group 'wheel' the right to do this.
2. An desktop user invoking a setup component which requires more privileges. AFAICS using su with root password for this use-case would be sufficient.
However, when you google for the way to do something, the answer always include sudo this, sudo that.
Just referring to Google foo is not a decent requirements engineering.
Whatever solution openSUSE comes up with the above use-cases have to considered more thoroughly.
I'm not referring to Google foo. You misunderstood me.
I say that when people google the solution to do _anything_ in Linux and uses google (even help people will tell people now and then to google before asking), they will be told to use sudo.
For example, google "howo to mount external disk" the first answer is:
<https://www.tomshardware.com/how-to/mount-drives-linux>
which says:
sudo mkdir /media/pendrive
sudo mount /dev/sdb1 /media/pendrive
sudo umount /media/pendrive
sudo mkdir /media/iso
sudo mount -o loop Downloads/fossapup64-9.5.iso /media/iso
etc.
The same will happen for any question you ask.
People will use sudo instead of su with openSUSE because google tells people to use sudo, not su. That's a fact and we can not change it.
Even if sudo is not the openSUSE way of doing things.
So people need sudo to work, proven by the many people having problems this weekend.
nop, i never use sudo, even if google tells me that, reason is: for your example i have to use 5 times sudo, but if i once enter su i am fine. maybe i am to stupid, i never got why i have to using sudo. i am also to stupid to got (in past) debian to work with isdn. so i ended up with opensuse. and maybe that's the reason why i use su and do not use sudo. but i am willing to learn, so if you could explain me why i should use sudo instead of su..... ? simoN -- www.becherer.de ----------------------------------------------- - Das ist die vorlaeufig endgueltige Version! - Herbert C. Maier Dipl.-Ing. (FH) -----------------------------------------------
On 2022-11-08 19:42, Simon Becherer wrote:
Am 08.11.22 um 19:24 schrieb Carlos E. R.:
On 2022-11-08 17:51, Michael Ströder wrote:
...
People will use sudo instead of su with openSUSE because google tells people to use sudo, not su. That's a fact and we can not change it.
Even if sudo is not the openSUSE way of doing things.
So people need sudo to work, proven by the many people having problems this weekend.
nop, i never use sudo, even if google tells me that, reason is: for your example i have to use 5 times sudo, but if i once enter su i am fine.
You don't have to convince me :-) I'm only saying that people are doing that, and my explanation of why is because that's what you find with google when searching. We lost that battle.
maybe i am to stupid, i never got why i have to using sudo. i am also to stupid to got (in past) debian to work with isdn. so i ended up with opensuse. and maybe that's the reason why i use su and do not use sudo.
but i am willing to learn, so if you could explain me why i should use sudo instead of su..... ?
There are reasons to use sudo, yes. One is lazy pasting of commands found in instructions on sites :-D But a serious one is that sudo logs every command used, so that if something goes bad (specially on a server where there are different admins doing different things) the log can be checked to see where was the mistake, and who did it. For home, it doesn't matter. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 11/8/22 19:42, Simon Becherer wrote:
i never use sudo, even if google tells me that, reason is: for your example i have to use 5 times sudo, but if i once enter su i am fine. And that's also how I'm doing it on my personal desktop system.
Well, you could also do: sudo su - ;-)
but i am willing to learn, so if you could explain me why i should use sudo instead of su..... ?
It depends on the use-case: An admin maintaining a remote system for which no (known) root password was set probably has to use sudo with his personal password. (It might be possible to also use su with some specific PAM config but it's rather unusual.) And as said recent sudo versions now provide additional features like audit logging. Ciao, Michael.
On 11/8/22 19:24, Carlos E. R. wrote:
I say that when people google the solution to do _anything_ in Linux and uses google (even help people will tell people now and then to google before asking), they will be told to use sudo.
No problem. The question is which password they have to type. Ciao, Michael.
On 2022-11-08 20:41, Michael Ströder wrote:
On 11/8/22 19:24, Carlos E. R. wrote:
I say that when people google the solution to do _anything_ in Linux and uses google (even help people will tell people now and then to google before asking), they will be told to use sudo.
No problem. The question is which password they have to type.
I prefer it to be the authorized user's password. If they know the root password, they don't need sudo :-) In my personal case, sudo can not run any command, only a list of them depending on user. Very restrictive, for no particular reason. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
participants (26)
-
Aaron Puchert -
Andrei Borzenkov -
AW -
Ben Holmes -
Carlos E. R. -
Carlos E. R. -
Cor Blom -
Darin Perusich -
Dominique Leuenberger / DimStar -
Dr. Werner Fink -
Jan Engelhardt -
Jason Sikes -
Jim Henderson -
jmscdba＠gmail.com -
Luciano Santos -
Ludwig Nussel -
Marcus Meissner -
Mathias Homann -
Michael Ströder -
Richard Brown -
Robert Webb -
Scott Bradnick -
Simon Becherer -
Stefan Seyfried -
Thorsten Kukuk -
Vojtěch Zeisek