On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote: > (I am not convinced that default umask should be changed)
Neither am I. But more to the point, it appears that the default umask literally *cannot* be changed in any kind of universal way. There are, like, half a dozen different places you'd have to apply a change in order to cover just the *most common* workflows. Who knows how many more corner cases would be missed? On Tue, Jul 16, 2024 at 07:53:31 +0700, Max Nikulin wrote: > First of all, it is up to display manager to read or to ignore ~/.profile > and ~/.xsessionrc. SDDM reads them. However it affects only > /usr/bin/startplasma-x11 subtree. Most user applications are started under > "/lib/systemd/systemd --user" So, this is a variant of the same problem we observed with GNOME a few years ago, just with systemd --user instead of dbus. Desktop Environments are not the parent processes of the programs that they run. This means there's no way for end users to configure the environments of their own programs. > https://wiki.archlinux.org/title/umask#Set_umask_value_for_KDE_/_Plasma This one gives two alternatives, both of which require editing files as root. > systemd.exec(5) > > > UMask= > > Controls the file mode creation mask. Takes an access mode in octal > > notation. See umask(2) for details. Defaults to 0022 for system units. > > For user units the default value is inherited from the per-user service > > manager (whose default is in turn inherited from the system service > > manager, and thus typically also is 0022 — unless overridden by a PAM > > module). In order to change the per-user mask for all user services, > > consider setting the UMask= setting of the user's user@.service system > > service instance. The per-user umask may also be set via the umask field > > of a user's JSON User Record[5] (for users managed by > > systemd-homed.service(8) this field may be controlled via homectl > > --umask=). It may also be set via a PAM module, such as pam_umask(8). [5] refers to <https://systemd.io/USER_RECORD>. I defy any human being to read that web page and tell me WHAT FILE TO EDIT, and WHAT TO PUT IN IT, to effect a change to your environment. I can't find anything concrete in there. Just a bunch of jabber. The only filename I could find by skimming that thing was ~/.identity, and that's buried *deep* inside the page. Is that the file you're supposed to create and/or edit? What do you put in it to make your programs have a umask of your choosing? Is there an example? > https://github.com/systemd/systemd/issues/16963#issuecomment-689656886 > poettering commented Sep 9, 2020 > > The user@.service templated system service is instantiated for each > > user. It's a system service like any other, hence you can extend it via > > drop-ins, and thus configure UMask= for it, like for any other system > > service. e.g. > > > > mkdir -p /etc/systemd/system/user@1000.service.d > > cat > /etc/systemd/system/user@1000.service.d/umask.conf<<EOF > > [Service] > > UMask=0007 > > EOF > > systemctl daemon-reload So, this way requires root privileges as well. How does an ordinary user modify *THEIR OWN ENVIRONMENT* without superuser access? If you don't use a Desktop Environment, then this is ridiculously simple. You put the commands to alter your environment in your ~/.profile or equivalent for your shell, for your shell logins. You put the commands in ~/.xsessionrc (on Debian), for your X sessions, if you use a Display Manager to login. (If you use startx, you don't even have to do that; your X session will inherit the environment from your login shell.) All of the programs you run, other than cron jobs, will inherit their environment either from your login shell, or from your X session. So this works. In a DE, this is just impossible to do. Why are Desktop Environments so *stupidly broken*? Why don't their developers seem to *care*?
