You are not logged in.

#1 2019-03-17 08:35:38

apollo22
Member
Registered: 2018-04-13
Posts: 34

XDG_BASE_DIRECTORY and system wide utilities

While reading this document, I noticed the part where system wide utilities may have difficulties to find the correct directories.

So far, I believe the only way to detect the user specified directories is to parse the shell configuration file from that user (which may not be reliable if the user source other files in its shell configuration. In case the user source multiple files, the parsing utility could also parse any source file.

Do you know of any other way to do it currently ?

Otherwise, what do you think about the following way to make the XDG variables known to the system:

  - .xdg_base_directory in a user $HOME, containing the variables (kind of like the user-dirs.dirs file)
  - system dabase that extract the variables when a user login (I have no idea if that can be implemented, but I think this would be kind of heavy, and remove some user control)

Offline

#2 2019-03-17 11:08:52

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: XDG_BASE_DIRECTORY and system wide utilities

You did notice that proposal is from 2004 ?


No need to parse sourcefiles , Check https://specifications.freedesktop.org/ … ec/latest/ .

There are specific environment variables that can be checked like $XDG_CACHE_HOME .


This sounds like an x-y problem what is your goal ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2019-03-17 11:30:59

apollo22
Member
Registered: 2018-04-13
Posts: 34

Re: XDG_BASE_DIRECTORY and system wide utilities

The problem is that those variables are modified by the user in their shell configuration file.

Say I want to write a program, run by the system (so no access to user environment variables, as the user might not even be logged in). This program wants to backup only the XDG_CONFIG_HOME of all the users. How would you do it ?

Offline

#4 2019-03-17 11:59:22

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: XDG_BASE_DIRECTORY and system wide utilities

Those variables can also be changed from commandline, parsing shell config files won't be enough.

I'd implement some way to restrict the users options.

One option would be to have a policy where only default folders will be backupped ( $home/.config for $XDG_CONF_HOME) . If the user sets another location for $XDG_CONF_HOME they need to arrange their own backup solution.

- Switch from local users to a system where users have less rights .
Domain users where domain admins/policies enforce some settings on login come to mind.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#5 2019-03-17 12:24:06

apollo22
Member
Registered: 2018-04-13
Posts: 34

Re: XDG_BASE_DIRECTORY and system wide utilities

Lone_Wolf wrote:

Those variables can also be changed from commandline, parsing shell config files won't be enough.

I believe this defeats the purpose of having ONE folder for each category, limiting this usage to either applications we want to separated from the standard ones (out of the scope of the subject I believe), or scripts that do not have access to the environments.

In the latter case,  this duplicates the places where the information can be found, leading to harder maintenance if we want to modify the locations. One more reason where it would be interesting to have those variables in a known place.

Lone_Wolf wrote:

I'd implement some way to restrict the users options.

One option would be to have a policy where only default folders will be backupped ( $home/.config for $XDG_CONF_HOME) . If the user sets another location for $XDG_CONF_HOME they need to arrange their own backup solution.

Say instead of backups I want to recover some space, deleting the users cache. I can't trust the users to arrange their own solution, nor can I trust them to keep the default location.

Lone_Wolf wrote:

- Switch from local users to a system where users have less rights .
Domain users where domain admins/policies enforce some settings on login come to mind.

The solution aims to be system agnostic, not depending on a specifig implementation. So in my mind the two solutions above do not fit.

Why does the specification use environment variable and not a file for those variables ? (I think ENV is better from I/O / access speed / file locks perspectives) But why not source those variables from a known file ?

This would pose the problem of where should this file be ?
  - In $HOME
  - User dependant. In this case:
    - From a user perspective, the file could just be sourced from it's location.
    - From the system perspective, you need a way to uniquely identify this file in the user home directory. Maybe using the hash method proposed in the previous document ?

Offline

#6 2019-03-17 12:58:37

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: XDG_BASE_DIRECTORY and system wide utilities

I think this is a sort of chicken-or-egg problem that most system-wide utilities have to fight with.

You'll notice for instance that OpenSSH also keeps its stuff in ~/.ssh and doesn't comply with the XDG basedir spec, because (for the server) the alternative would be to start a full-fledged session for a given user, inspect the environment to extract some (e.g. XDG-b-d-s) variable, determine where the user keeps their authorized_keys file, and only then determine whether the remote user even has the permission to log in.

Not only is this very impractical, it also doesn't take into account the fact that the environment may differ on the method used to "log in". The systemd user session runs a different set of environment variables (influenced by pam_environment and environment.d) than a regular shell login session (pam_environment and shell profile files), and again different from a desktop session (pam_environment and xprofile for a DE—pam_environment, shell profile files, and xinitrc for startx); how should the system service determine which one is the environment that tells the "truth"?

(I could go on for hours complaining about this, but here is a…)

Proposal

Wouldn't it be possible to change your system to run as a user service? Statically enable a user service/timer in /etc/systemd/user (so out of reach for users to screw up, but still running in their context), and the program then runs in the user environment (which the user may then configure as desired with pam_environment and environment.d).

The rest is then as always: use XDG_CACHE_HOME and fall back to ~/.cache if it's not set.


pkgshackscfgblag

Offline

#7 2019-03-17 13:07:02

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: XDG_BASE_DIRECTORY and system wide utilities

As it's a system (root) service you're talking about, it could easily su or login as each user, and in doing so, parse all their profile/rc files getting any user-specified enviornment variables - though this would not be a great idea, and would not solve your problem in any way:

apollo22 wrote:

I believe this defeats the purpose of having ONE folder for each category

Allowing user's to specify environment variables for this folder already defeated that purpose.  You can either have one statically determined location for each category/user, or you can let the location be dynamically determined by user-specified environment variable settings.  This isn't even a coding or software limitation, this is a fundamental flaw in your reasoning of wanting to acheive two mutually exclusive goals.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2019-03-17 14:01:18

apollo22
Member
Registered: 2018-04-13
Posts: 34

Re: XDG_BASE_DIRECTORY and system wide utilities

ayekat wrote:

I think this is a sort of chicken-or-egg problem that most system-wide utilities have to fight with.

You'll notice for instance that OpenSSH also keeps its stuff in ~/.ssh and doesn't comply with the XDG basedir spec, because (for the server) the alternative would be to start a full-fledged session for a given user, inspect the environment to extract some (e.g. XDG-b-d-s) variable, determine where the user keeps their authorized_keys file, and only then determine whether the remote user even has the permission to log in.

This is actually the perfect exemple of a service facing this issue, thanks.

ayekat wrote:

Wouldn't it be possible to change your system to run as a user service?

The question I am asking is theoretical, I am not currently facing the issue.

Trilby wrote:

Allowing user's to specify environment variables for this folder already defeated that purpose.  You can either have one statically determined location for each category/user, or you can let the location be dynamically determined by user-specified environment variable settings.  This isn't even a coding or software limitation, this is a fundamental flaw in your reasoning of wanting to acheive two mutually exclusive goals.

I am not sure I understand what you mean. (Or that you understand what I meant ? ) I don't think I ever said that the file could be both statically linked and dynamically located.

I think dynamically locating files based on their category (cache, data, config) is better from a user perspective. This is why I would like your thoughts on how this could be done (or even implemented while coexisting with the current XDG_BASE_DIR specification).

Offline

#9 2019-03-17 15:54:17

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: XDG_BASE_DIRECTORY and system wide utilities

You want one specific folder right?  This is completely at odds with the goal of letting a user specify whatever directory they want: they can change their config files at will.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2019-03-17 17:19:06

apollo22
Member
Registered: 2018-04-13
Posts: 34

Re: XDG_BASE_DIRECTORY and system wide utilities

I mean using one folder cache (as in ~/.cache), one for data (~/.local/share), one for config (~/.config) using XDG_BASE_DIR. And allowing the user the choice to move those folders (for exemple relocating ~/.local/share to ~/.data).

Offline

Board footer

Powered by FluxBB