Friday 29 May 2020

Re: Adjusting what fstypes df displays

On Thu, May 28, 2020 at 09:38:47PM -0700, Bryce Harrington wrote:
> For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> /etc/profile.d/ perhaps?) This would make it straightforward to add

Many thanks for working on this, df output has been annoying me for quite
some time (but I dislike shell aliases even more).

Properly threading an environment variable into a given process is
surprisingly difficult. /etc/profile.d/ is read by bash, and other
shells that choose to use these startup files. /etc/environment is
used by any PAM service that has pam_environment configured and
systemd-environment-d-generator(8) for systemd user manager instances.

These may not cover all instances where users would like it to. And,
ironically, even though it doesn't cover everything, it would be in the
memory of many processes that may never call df. It's not like it's a
huge amount of memory, but it is something.

Different tools like sudo, su, systemd-nspawn, lxc exec, etc may
further complicate getting an environment variable through from where a
human is interacting with the system to where df is executing.

So, I'd like to propose using the typical systemd-style configuration file
approach instead:

Package defaults in:
/lib/something/coreutils/df.conf or
/usr/lib/something/coreutils/df.conf

Sysadmin configuration in:
/etc/something/coreutils/df.conf

User configuration in:
XDG_SOMETHING_CONFIG/coreutils/df.conf
or
/run/uid/something/coreutils/df.conf

Yes, it's exhausting to implement the functionality for all this compared
to the simplicity of a getenv() or secure_getenv(), but filesystem access
is more predictable than environment variables from parents to children
and will likely work closer to expectations across chroot, schroot, lxd,
etc uses.

If we ever want to change the package defaults, then any local admin
choices already made could continue to be respected.

Thanks