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.

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