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
>
> 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)