umask - default user settings?

[Greg Wooledge]

I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.

The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.

If you don't like this setting, change it.

[Hans]

Hi Greg,

yes, did already change it. However, this looks like a security hole for me,
as I believe, not many people or admins are changing this.

IMO debian should change this in the next release, but I doubt it.

I will ask the security team for it, they will decide.

Have fun!

Hans

Post by Greg Wooledge

I am wondering, why on a multiuser system like debian the rights for a
normal user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.
The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.
If you don't like this setting, change it.

[Greg Wooledge]

Post by Hans
Hi Greg,
yes, did already change it. However, this looks like a security hole for me,
as I believe, not many people or admins are changing this.
IMO debian should change this in the next release, but I doubt it.
I will ask the security team for it, they will decide.

It is NOT a security issue. Any files that contain secret data are
protected by their individual permissions, as set by the programs
that create them. Like your ssh private keys:

hobbit:~$ ls -l .ssh
total 72
...
-rw------- 1 greg greg 1876 Sep 24 2019 id_rsa
-rw-r--r-- 1 greg greg 394 Sep 24 2019 id_rsa.pub

The other 99.9% of your files are not secret, so they don't need to
be hidden.

[Nicolas George]

Greg, I do not agree. If I am writing a document with private content, then I

If you are writing something confidential, it is your responsibility to
lock the door of your office.

Regards,

[Hans]

I see itthe other way round. No, if you are in the secure area, it is the
responsibility of the owner to make it secure by design i.e with dself closing
doors where you can not look into or windows with curtains.

However, I presume, debian wants to be secure. If no one cares and all agree
with this (in my personal opinion!) security whole, I will have to accept
this. For myself I found a solution of course, and I just could have not told
about it, but I cared for others and tried to put my 2 cents in it, to improve
the security of debian.

If this is too much, then we can close this issue at once. Shall we?

Hans

Post by Nicolas George
If you are writing something confidential, it is your responsibility to
lock the door of your office.
Regards,

[Max Nikulin]

Post by Hans
I see itthe other way round. No, if you are in the secure area, it is the
responsibility of the owner to make it secure by design i.e with dself closing
doors where you can not look into or windows with curtains.

The door is closed by default in bookworm. User home directories are
created with 0700 mode, see /usr/share/doc/adduser/README.gz and
/usr/share/doc/adduser/NEWS.Debian.gz As a result, it is necessary to
set ACLs e.g. to run unprivileged LXC containers.

RedHat likely has 0700 for $HOME for much longer time.

Put your confidential files in directories not readable by others. You
may consider keeping these directories encrypted.

In the past it was not uncommon to have ~/public_html accessible to web
server. Once I have faced requirement to explicitly set selinux context
for this directory. I do not know if it was default for that linux
distribution or configured by the administrator.

[Hans]

Post by Max Nikulin
The door is closed by default in bookworm. User home directories are
created with 0700 mode, see /usr/share/doc/adduser/README.gz and
/usr/share/doc/adduser/NEWS.Debian.gz As a result, it is necessary to
set ACLs e.g. to run unprivileged LXC containers.

That is not the point. The point us, that debian is creating a default user
"for your daily work" at installation with umask 022.

And we are not talking about experienced users, but of linux beginners. I
doubt, they are aware of umask and rights and so.

Debian is made for every people, not only for experienced people.

Yes, when adduser cares about, this is one good step, but does not touch my
argumentation. Also, when some other applicatiions are setting correct rights.
Some do, some don't.

That is not the point, too. The point is, should't we do it completely and
make it standard by default - also and especially during installation to make
debian more secure for unexprienced users and linux noobs?

Best

Hans

[Greg Wooledge]

Post by Hans
Also, when some other applicatiions are setting correct rights.
Some do, some don't.

File bug reports against the ones which don't.

[Hans]

Greg, I do not agree. If I am writing a document with private content, then I
do not want to let it be read by someone else except me.

No one has to read any letters or cv's or maybe documents for my lawyer, my
medic, my friends or whatever.

And after years there are a lot of documents one is writing, many private
things.

And i think, no one wants to sharew these with other users on the system!

At least, I won't.

Best

Hans

Post by Greg Wooledge
hobbit:~$ ls -l .ssh
total 72
...
-rw------- 1 greg greg 1876 Sep 24 2019 id_rsa
-rw-r--r-- 1 greg greg 394 Sep 24 2019 id_rsa.pub
The other 99.9% of your files are not secret, so they don't need to
be hidden.

[Alan D. Salewski]

Post by Hans
Hi Greg,
yes, did already change it. However, this looks like a security hole for me,
as I believe, not many people or admins are changing this.

I suspect that most people /do/ change it, once they become aware of
it, for the very reason stated in the comment above 'UMASK' in the
/etc/login.defs file:

<quote>
# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
...
UMASK 022
</quote>

Post by Hans
IMO debian should change this in the next release, but I doubt it.

I do not feel strongly about it, but I am sympathetic with the point
of view that having a default umask of, say, 077 would be a better
default for many unwary Day 1 *nix users. I think it is reasonable
for somebody to expect that that something is not accessible by
group or others unless the user explicitly made it so.

I have no idea how such a change might affect backward
compatibility. I'm guessing not much, since the umask value is one
of those things that tends to get set explicitly when it matters
(beyond the user's need to read or write their own files).

The user's umask value would matter less if the default perms of
user $HOME directories were 077, since then even files created with
unintentionally looser perms could not be viewed by group or
others[0]. As it is, it looks[1] like default perms for $HOME are
0755.

Post by Hans
I will ask the security team for it, they will decide.
Have fun!
Hans

-Al


[0] Assuming most files created by a user are created beneath that
user's $HOME.

[1] Just did an empirical test by spinning up a Debian 12.x
("Bookworm") AWS AMI, $HOME directories have perms 0755:

$ ls -la /home
total 12
drwxr-xr-x 3 root root 4096 Jul 14 22:32 .
drwxr-xr-x 18 root root 4096 Jul 14 22:32 ..
drwxr-xr-x 3 admin admin 4096 Jul 14 22:32 admin

[Greg Wooledge]

Post by Alan D. Salewski
As it is, it
looks[1] like default perms for $HOME are 0755.

If home directories are created with adduser, then the contents of
/etc/adduser.conf are relevant:


# The permissions mode for home directories of non-system users.
# Default: DIR_MODE=0700
#DIR_MODE=0700

# The permissions mode for home directories of system users.
# Default: SYS_DIR_MODE=0755
#SYS_DIR_MODE=0755


If they're created by something else, then it depends on what that other
creation method is.

[Alan D. Salewski]

On 2024-07-14 22:15:34, "Alan D. Salewski" <***@att.net> spake thus:
[...]

Post by Alan D. Salewski
The user's umask value would matter less if the default perms of
user $HOME directories were 077

s/were/were from a umask of/

[Emanuel Berg]

Here is some cool ascii art to illustrate permissions
after mount.

The (x)_b notation indicates that x is in base b.

# permissions
# rwxr-xr-x dirs
local dmask=022 # (22)_8 = ( 10010)_2
local fmask=133 # (133)_8 = ( 1011011)_2
# rw-r--r-- files
#

[Max Nikulin]

I suspect that most people /do/ change it, once they become aware of it,
for the very reason stated in the comment above 'UMASK' in the
<quote>
    # UMASK is the default umask value for pam_umask and is used by
    # useradd and newusers to set the mode of the new home directories.
    # 022 is the "historical" value in Debian for UMASK
    # 027, or even 077, could be considered better for privacy
    # There is no One True Answer here : each sysadmin must make up
his/her
    # mind.
    ...
    UMASK       022
</quote>

Have you tried to change it?

<https://bugs.debian.org/583958>
<https://bugs.debian.org/646692>
pam_umask: umask in /etc/login.defs not respected cause libpam_umask is
not configured
Fixed in versions pam/1.5.3-1, pam/1.5.3-4
Wed, 28 Feb 2024 05:31:34 +0000

Not to mention systemd user sessions discussed in another branch of this
thread.

[Greg Wooledge]

Setting umask in your shell profile isn't that hard indeed. I've doing that
for years. However, that does not mean your DE will honour that setting. I
have tried to do so for KDE (more specifically Krusader), but I ended up
nowhere. I haven't found a setting that will be honoured KDE wide or even
just in Krusader alone.

I remember someone trying to do the same thing in GNOME several years
ago, and nobody could find a solution for GNOME, either.

With a traditional window manager, it's as simple as can be. You just
set umask in your ~/.xsession file (before exec-ing your WM) and you're
done. I don't know why the creators of Desktop Environments have decided
to discard all common sense.

[Lists]

Post by Greg Wooledge

I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.
The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.
If you don't like this setting, change it.

Setting umask in your shell profile isn't that hard indeed. I've doing
that for years. However, that does not mean your DE will honour that
setting. I have tried to do so for KDE (more specifically Krusader), but
I ended up nowhere. I haven't found a setting that will be honoured KDE
wide or even just in Krusader alone.

Grx HdV

[t***@tuxteam.de]

Post by Greg Wooledge

I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.
The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.
If you don't like this setting, change it.

Setting umask in your shell profile isn't that hard indeed. I've doing that
for years. However, that does not mean your DE will honour that setting. I
have tried to do so for KDE (more specifically Krusader), but I ended up
nowhere. I haven't found a setting that will be honoured KDE wide or even
just in Krusader alone.

The place to do this is the X session [1]; system-wide in
/etc/X11/Xsession.d/... and for each user in ~/.xsessionrc.
You might have to set allow-user-session in the global config
/etc/X11/Xsession.options to make the second possible.

Cheers

[1] https://wiki.debian.org/Xsession

[Greg Wooledge]

Post by t***@tuxteam.de

Setting umask in your shell profile isn't that hard indeed. I've doing that
for years. However, that does not mean your DE will honour that setting.

The place to do this is the X session [1]; system-wide in
/etc/X11/Xsession.d/... and for each user in ~/.xsessionrc.
You might have to set allow-user-session in the global config
/etc/X11/Xsession.options to make the second possible.

Does that work in KDE? As we discovered a few years ago, it doesn't
work in GNOME. GNOME specifically starts up its terminal emulators
via dbus or something, so they aren't children of the GNOME top-level
process, and don't inherit the umask or environment from the session.

I'm totally willing to believe that KDE is different, but it's not
clear whether "Lists" has tried this and failed, or simply didn't know
that it should be done this way.

It would be excellent to receive confirmation from a KDE user, either
way.

[t***@tuxteam.de]

[...]

Post by Greg Wooledge
Does that work in KDE?

At least The Internet (TM) (from some cursory poking) seems to
say so. I stay away from DEs for... reasons, so I can't test
it.

Post by Greg Wooledge
As we discovered a few years ago, it doesn't
work in GNOME. GNOME specifically starts up its terminal emulators
via dbus or something,

Gah. What a bad taste. One reason more to stay away from DEs.

Post by Greg Wooledge
so they aren't children of the GNOME top-level
process, and don't inherit the umask or environment from the session.
I'm totally willing to believe that KDE is different, but it's not
clear whether "Lists" has tried this and failed, or simply didn't know
that it should be done this way.
It would be excellent to receive confirmation from a KDE user, either
way.

I'd be curious, too.

Cheers

[Franco Martelli]

Post by t***@tuxteam.de

Post by Greg Wooledge
so they aren't children of the GNOME top-level
process, and don't inherit the umask or environment from the session.
I'm totally willing to believe that KDE is different, but it's not
clear whether "Lists" has tried this and failed, or simply didn't know
that it should be done this way.
It would be excellent to receive confirmation from a KDE user, either
way.

I'd be curious, too.

KDE provides a special purpose directory for setting the environment
globally: ~/.config/plasma-workspace/env/
In addition it is possible to specify environment variables for every
application singularly by editing the "Start" menu.
In that directory must be placed executable shell scripts that configure
the environment e.g.:

~$ ls -l ~/.config/plasma-workspace/env/kwin_env.sh
-rwxr-xr-x 1 frank frank 97 15 lug 15.38
/home/frank/.config/plasma-workspace/env/kwin_env.sh

~$ cat ~/.config/plasma-workspace/env/kwin_env.sh
#!/bin/sh

export KWIN_TRIPLE_BUFFER=1
/usr/bin/picom -b --config ~/.config/picom.conf

I tried to add "umask 027" to the bottom of "kwin_env.sh" file but that
change it doesn't apply to xterm.
Is there any other syntax to specify the umask? What's in your .xsessionrc?

Cheers

[Max Nikulin]

Post by Greg Wooledge

Post by t***@tuxteam.de
The place to do this is the X session [1]; system-wide in
/etc/X11/Xsession.d/... and for each user in ~/.xsessionrc.

Does that work in KDE?

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"

https://wiki.archlinux.org/title/umask#Set_umask_value_for_KDE_/_Plasma

Post by Greg Wooledge
Setting the umask value via /etc/profile does no longer work for KDE /
Plasma sessions because these are started as systemd user units.

...and some recipes.

[Me]

Post by t***@tuxteam.de

Post by Greg Wooledge

I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.
The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.
If you don't like this setting, change it.

Setting umask in your shell profile isn't that hard indeed. I've doing that
for years. However, that does not mean your DE will honour that setting. I
have tried to do so for KDE (more specifically Krusader), but I ended up
nowhere. I haven't found a setting that will be honoured KDE wide or even
just in Krusader alone.

The place to do this is the X session [1]; system-wide in
/etc/X11/Xsession.d/... and for each user in ~/.xsessionrc.
You might have to set allow-user-session in the global config
/etc/X11/Xsession.options to make the second possible.
Cheers
[1] https://wiki.debian.org/Xsession

Did you actually try this? I did and it did not what I was expecting it
to do. But maybe I should try again, maybe things have improved in the
meanwhile.

Grx HdV

[t***@tuxteam.de]

[...]

Post by t***@tuxteam.de
[1] https://wiki.debian.org/Xsession

Did you actually try this? I did and it did not what I was expecting it to
do. But maybe I should try again, maybe things have improved in the
meanwhile.

Me? As I said, I don't use desktop environments. Just plain X and a
window manager (Fvwm). For me, .xsessionrc works beautifully. I had
to enable it in /etc/X11/Xsession.options (back then, maybe Jessie or
Stretch) and this has travelled across upgrades to now.

So no complaints from me :)

Cheers

[Teemu Likonen]

Setting umask in your shell profile isn't that hard indeed. I've doing
that for years. However, that does not mean your DE will honour that
setting. I have tried to do so for KDE (more specifically Krusader), but
I ended up nowhere. I haven't found a setting that will be honoured KDE
wide or even just in Krusader alone.

I think nowadays systemd has to be told about new umask value. Many
things are branched from ***@.service unit. So, perhaps like this:

# /etc/systemd/system/***@.service.d/my-umask.conf

[Service]
UMask=0007

[Thomas Schmitt]

Hi,

I am wondering, why on a multiuser system like debian the rights for a
normal user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Because the usual umask of 0022 keeps the more credulous programs from
giving w-permission to everybody.
Any program is free to hand out restricted permission. umask just defines
what such a program shall not get done immediately when the file is
created. Afterwards a program can still widen permissions.

First two are clear: rw for myself, and readable for all users, i am
allowing into my own grou.

It's not necessarily your group, but rather the group to which the file
belongs. This is typically the group of the process of the program which
creates the file. (Unless it has superuser powers and can change the group
id.)

Shell command "id" can tell your current shells user id and group id
which in most cases are inherited by programs which you start.

$ id
id=number(name) gid=number(name) groups=number(name),...

But there are the programs which are allowed to run under a self chosen
user and group id. (See man 1 chmod permission "s" and man 2 setgid.)


Have a nice day :)

Thomas

[Me]

Post by Greg Wooledge

I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)

Tradition, and a culture based around sharing.
The Unix culture of openness and freedom (specifically the freedom to
distribute your work to others) works best if you can say "Hey Betty,
can you take a look at my .bashrc? I can't get my foo() function to
work." Or "Hey friends, I've made some changes to my bar.c file that
you might want to look at." And then they can just read the files
directly from your home directory.
If you don't like this setting, change it.

Setting umask in your shell profile isn't that hard indeed. I've doing
that for years. However, that does not mean your DE will honour that
setting. I have tried to do so for KDE (more specifically Krusader), but
I ended up nowhere. I haven't found a setting that will be honoured KDE
wide or even just in Krusader alone.

Grx HdV

[Lists]

Setting umask in your shell profile isn't that hard indeed. I've doing
that for years. However, that does not mean your DE will honour that
setting. I have tried to do so for KDE (more specifically Krusader), but
I ended up nowhere. I haven't found a setting that will be honoured KDE
wide or even just in Krusader alone.
Grx HdV

Twice? My apologies for that. Must have sent that without realising it.

Grx HdV

[Eduardo M KALINOWSKI]

Dear list,
I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)
Of course there is a reason for this, but it is not understandable for me.
First two are clear: rw for myself, and readable for all users, i am allowing
into my own grou.
The last one is not clear for me. Why should I allow the rest of the world
read my personal documents? These are private and no one else should be able
to read them!
So I would have expected a setting of "rw- r-- ---" for any files.
Before someone argues, "you can change this by editing umask", yes, I know of
this of course.
But it is not clear for me, why it is set that way by default and not as I
would have expected as described above.
Sure, there is a reason for this, so I will be happy, if someone could
enlighten me.

I kind of agree with that in principle, and I've always used an umask
077 myself.

On the other hand, I'm the only user in my system, so it doesn't really
matter. I expect that is the case for most users.

I'm not sure if the Debian default should be changed, though.

[Lists]

Post by Eduardo M KALINOWSKI
I'm not sure if the Debian default should be changed, though.

One thing to consider is that in modern software development practices
the idea of secure/private by default is getting more and more important
and implemented. It is good practice to protect yourself and your users
against mistakes. I know things can be done to set a proper mask, but
why not opt for the same stance that firewalls have adopted long ago,
being "deny by default"? In some cases that might make a system harder
to use, but I don't see how that could be the case in a user's home
directory.

Just my 2 cents.

Grx HdV

[Greg Wooledge]

If people on this mailing list are so concerned about other people's
umasks, then I would suggest a great starting point would be to start by
making it POSSIBLE for other people to set their umasks the way they want.

If you use a Desktop Environment, go to your DE's support mailing list,
and ask them how to set your umask so that it works as expected in all
of your programs. This must include programs that are launched at login,
and programs that are launched by a menu or icon, and terminal emulators
(and not merely the shells that run inside terminal emulators).

Make sure whatever solution they give you applies regardless of whether
a program is launched as a child of a window manager, or a child of
a systemd user session, or a child of dbus.

If they can't give you a solution that works in all of these cases,
**make them fix their stupid software**. Do not let up until they have
given their users a way to configure their environments as needed.

Once all of the Desktop Environments provide a way to do what you want,
**then** you might think about leaning on Debian to change their defaults.
That will be a separate battle, but it's not a battle you can currently
even **begin** fighting.

Also bear in mind, this is the Debian **user** mailing list, and none of
us have any power whatsoever over the Debian project. Let alone over
the various Desktop Environments.

[Max Nikulin]

Post by Greg Wooledge
If you use a Desktop Environment, go to your DE's support mailing list,
and ask them how to set your umask so that it works as expected in all
of your programs.

(I am not convinced that default umask should be changed)

systemd.exec(5)

Post by Greg Wooledge
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,
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).

https://github.com/systemd/systemd/issues/16963#issuecomment-689656886
poettering commented Sep 9, 2020

Post by Greg Wooledge
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.
[Service]
UMask=0007
EOF
systemctl daemon-reload

[Greg Wooledge]

Post by Max Nikulin
(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?

Post by Max Nikulin
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.

Post by Max Nikulin
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.

Post by Max Nikulin
systemd.exec(5)

Post by Teemu Likonen
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,
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?

Post by Max Nikulin
https://github.com/systemd/systemd/issues/16963#issuecomment-689656886
poettering commented Sep 9, 2020

Post by Teemu Likonen
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.
[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*?

[Jeffrey Walton]

Post by Greg Wooledge
[...]

Post by Max Nikulin
systemd.exec(5)

Post by Teemu Likonen
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,
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.

++

Post by Greg Wooledge
I can't find anything concrete in there. Just a bunch of jabber.

Welcome to the world according to Pottering.

Post by Greg Wooledge
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?

Jeff

[Max Nikulin]

Post by Greg Wooledge

Post by Max Nikulin
systemd.exec(5)

Post by Teemu Likonen
UMask=

[...]

Post by Greg Wooledge
[5] refers to <https://systemd.io/USER_RECORD>.

I do not have systemd-homed running (minimal KDE). I have no idea
concerning default Gnome installation. My expectation that is should
solve various issues with per-user encrypted directories and may be
suitable for remote home directories.

Post by Greg Wooledge

Post by Max Nikulin
https://github.com/systemd/systemd/issues/16963#issuecomment-689656886

Post by Teemu Likonen
[Service]
UMask=0007
EOF
systemctl daemon-reload

So, this way requires root privileges as well.

I have naively tried

cat ~/.config/systemd/user/service.d/umask.conf
[Service]
UMask=0007

From xterm and konsole:

umask
0007

It seem creating new files from Dolphin respect the setting as well. I
admit I may miss some use case when it is ignored, but at first glance I
do not see a clear reason to complain.

[Greg Wooledge]

Post by Max Nikulin
I have naively tried
cat ~/.config/systemd/user/service.d/umask.conf
[Service]
UMask=0007
umask
0007

OK. Let's follow this path a bit.

I googled "how to create a systemd user service" and got
<https://blog.victormendonca.com/2018/05/14/creating-a-simple-systemd-user-service/>.

Starting from there:

hobbit:~$ cd .config
hobbit:~/.config$ mkdir -p systemd/user
hobbit:~/.config$ vi systemd/user/xterm.service
hobbit:~/.config$ cat systemd/user/xterm.service
[Unit]
Description=Try to run an xterm

[Service]
Type=simple
StandardOutput=journal
ExecStart=/usr/bin/xterm

[Install]
WantedBy=default.target
hobbit:~/.config$ systemctl --user enable xterm.service
Created symlink /home/greg/.config/systemd/user/default.target.wants/xterm.service → /home/greg/.config/systemd/user/xterm.service.
hobbit:~/.config$ systemctl --user start xterm.service


This caused an xterm to popup. OK, so far so good. Apparently the
systemd --user process inherits my $DISPLAY, so it's able to launch an
xterm.

I closed the xterm, and then:

hobbit:~$ cd ~/.config/systemd
hobbit:~/.config/systemd$ ls
user/
hobbit:~/.config/systemd$ ls user
default.target.wants/ xterm.service
hobbit:~/.config/systemd$ cd user
hobbit:~/.config/systemd/user$ mkdir service.d
hobbit:~/.config/systemd/user$ vi service.d/umask.conf
hobbit:~/.config/systemd/user$ cat service.d/umask.conf
[Service]
UMask=0007


Then:

hobbit:~$ systemctl --user start xterm.service


I ran umask within this xterm, and got 0022. Next:

hobbit:~$ systemctl --user daemon-reload
hobbit:~$ systemctl --user start xterm.service


This time, umask gave me 0007.

So it looks like your technique works, allowing an end user to create a
systemd --user configuration file which affects all(?) of their
systemd --user services, if they have any.

I also performed this experiment:

hobbit:~$ vi .config/systemd/user/service.d/env.conf
hobbit:~$ cat .config/systemd/user/service.d/env.conf
[Service]
Environment="FOO=%h/test123" "BAR=b a r"
hobbit:~$ systemctl --user daemon-reload
hobbit:~$ systemctl --user start xterm.service


The resulting xterm had umask 0007, and the expected values in the FOO
and BAR environment variables (with %h expanded to my home directory,
as documented in systemd.unit(5)).

I'm assuming the two files in service.d/ can be merged, but I didn't
test that.

So, this is a highly positive result. (And surprising. Why isn't this
stuff documented in ALL the places??) It looks like there's a chance
that some Desktop Environments can be configured by end users after all.

Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward. Documentation would be my top priority. If other people want
to try to drum up interest in environment configuration, then there'll
be documentation available for end users to follow.

[Max Nikulin]

Post by Greg Wooledge

Post by Max Nikulin
cat ~/.config/systemd/user/service.d/umask.conf
[Service]
UMask=0007

I googled "how to create a systemd user service" and got

The following blog posts (0pointer.de) may be a bit outdated, but still
useful:
https://systemd.io/#the-systemd-for-administrators-blog-series

Post by Greg Wooledge
hobbit:~/.config$ cat systemd/user/xterm.service

I am a bit afraid that corner cases might exist because there are no
.service files for applications started from menus and runners

systemd-cgls

├─user.slice (#361)
│ └─user-1000.slice (#6090)
│ ├─***@1000.service … (#6182)
│ │ ├─session.slice (#6320)
│ │ ├─app.slice (#6274)
...
│ │ │ ├─app-org.kde.konsole-dfb8….scope (#8087)
│ │ │ │ ├─ 2572 /usr/bin/konsole
...
│ │ │ ├─app-debian\x2dxterm-e15c….scope (#14192)
│ │ │ │ ├─25859 /usr/bin/xterm

Post by Greg Wooledge
systemd --user process inherits my $DISPLAY

You may use

systemctl --user show-environment

Post by Greg Wooledge
[Service]
Environment="FOO=%h/test123" "BAR=b a r"

I do not remember if environment.d(5) has some issues that may be
avoided this way.

Post by Greg Wooledge
I'm assuming the two files in service.d/ can be merged, but I didn't
test that.

Certainly, however sometimes it is more convenient to manage independent
drop-ins.

Post by Greg Wooledge
So, this is a highly positive result. (And surprising. Why isn't this
stuff documented in ALL the places??)

Man pages for systemd is so long that sometimes it is easy to miss
something important. Sometimes systemd.index(7) and
systemd.directives(7) are not enough to find a specific topic.

Perhaps I have noticed service.d trick in output of "sustemctl cat" for
some service.

Post by Greg Wooledge
Top level per-type drop-ins can be used to change some aspect of all
units of a particular type. For example by creating the
/etc/systemd/system/service.d/ directory with a drop-in file,
Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward.

I do not have a recent live image on my disk to verify, but I expect
that nowadays Gnome uses systemd session as well. Desktop environments
that have not migrated to systemd likely still relies on Xsession.

[Greg Wooledge]

Post by Max Nikulin

Post by Greg Wooledge
hobbit:~/.config$ cat systemd/user/xterm.service

I am a bit afraid that corner cases might exist because there are no
.service files for applications started from menus and runners

Well, I don't have "menus and runners". I had to create *something*
I could use for testing, and that's what I came up with.

Post by Max Nikulin

Post by Greg Wooledge
Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward.

I do not have a recent live image on my disk to verify, but I expect that
nowadays Gnome uses systemd session as well. Desktop environments that have
not migrated to systemd likely still relies on Xsession.

There are very few GNOME users on this mailing list. We do not reflect
the typical Debian population very well at all. Most of us are older,
more traditional users, who favor plain window managers (fvwm and company)
or lighter Desktop Environments.

This makes it hard to support certain parts of Debian, and GNOME is
definitely on that "hard to support" list.

[Max Nikulin]

Post by Greg Wooledge

Post by Max Nikulin

Post by Greg Wooledge
hobbit:~/.config$ cat systemd/user/xterm.service

I am a bit afraid that corner cases might exist because there are no
.service files for applications started from menus and runners

Well, I don't have "menus and runners". I had to create *something*
I could use for testing, and that's what I came up with.

Running from a menu or a runner is similar to

systemd-run --user --scope --slice app.slice -- xterm

Accordingly to systemd-run(1), --scope causes environment inheritance
from starting process despite new process is moved to another branch of
cgroup tree.

However

│ │ │ ├─plasma-krunner.service (#8046)
│ │ │ │ └─2533 /usr/bin/krunner

and

│ │ │ ├─plasma-plasmashell.service (#7073)
│ │ │ │ └─2027 /usr/bin/plasmashell --no-respawn

that are parents in "ps xwf" process tree for runner and menu cases
accordingly are *services* and it explains why service.d overrides apply.

Greg, do you have an example when Environment= in service.d works, but
an environment.d file does not?

P.S. There is
<https://wiki.debian.org/Debate/umask>
from 2013 briefly discussing 022 vs. 002 values.

[Greg Wooledge]

Greg, do you have an example when Environment= in service.d works, but an
environment.d file does not?

Oh gods, there's MORE shit to worry about?? Of course there is.
Bloody hell.

In previous years, I remember exploring environment.d and discarding it,
because it never achieved the goals that I had in mind. At that time, I
was trying to find a shell-agnostic and login-style-agnostic way to set
environment variables for all login sessions (console, ssh, DM).

environment.d is not that.

But in this particular investigation, we're "only" trying to find a
way to configure the user environment for programs started by Desktop
Environments. So, back to the laboratory....

Given the existence of the following files:

-rw-r--r-- 1 greg greg 66 Jul 16 11:43 .config/environment.d/foo.conf
-rw-r--r-- 1 greg greg 51 Jul 15 23:24 .config/systemd/user/service.d/env.conf
-rw-r--r-- 1 greg greg 21 Jul 15 23:39 .config/systemd/user/service.d/umask.conf

And given that "systemctl --user daemon-reload" has been performed since
they were last edited, what I'm seeing is that the contents of the
environment.d file are applied *first*, and then the contents of the
service.d files are applied *second*, overriding whatever was in the
environment.d file.

Also, and this is *highly* noteworthy, the syntaxes are different.
In particular, expansions like %h are performed in the service.d files,
but *not* in the environment.d files.

On the other hand, environment.d(5) says you can use a limited subset of
shell expansion syntax. It might be worth investigating exactly what
variables are available for expansion at that time, but at first glance,
it looks like service.d with its %h is probably going to be more useful.

For anyone reading this in the archives, out of context, please note that
the contents of these files *do not* apply to user logins. They only
apply to programs started by the systemd --user daemon.

[t***@tuxteam.de]

Post by Greg Wooledge

Greg, do you have an example when Environment= in service.d works, but an
environment.d file does not?

Oh gods, there's MORE shit to worry about?? Of course there is.
Bloody hell.

[...]

Post by Greg Wooledge
For anyone reading this in the archives, out of context, please note that
the contents of these files *do not* apply to user logins. They only
apply to programs started by the systemd --user daemon.

Thanks for the interested read.

It reminds me of the horror stories we told each other when 14 or so, at
the campfire.

Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I
just retire before the alternatives aren't viable anymore. Or perhaps, as
with PulseAudio, I can leapfrog that "tech".

(The most probable outcome though is even less rosy: everything'll run in
the browser, and Secure Boot will make sure that your hardware refuses to
run anything else, because the chips are sponsored by the Ad Industry.

Oh, well).

Cheers

[Thomas Schmitt]

Hi,

Post by t***@tuxteam.de
Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I
just retire before the alternatives aren't viable anymore. Or perhaps, as
with PulseAudio, I can leapfrog that "tech".

Retirement is no solution.
What shall we retirees do when X11 is laid to rest ?
I am not aware of anything like fvwm running on Wayland.

Post by t***@tuxteam.de
(The most probable outcome though is even less rosy: everything'll run in
the browser,

Maybe we can run X11 and fvwm on a virtual outdated graphics board in a
browser window ?

Post by t***@tuxteam.de
and Secure Boot will make sure that your hardware refuses to
run anything else, because the chips are sponsored by the Ad Industry.

That would make not much difference to the end of fvwm.

"A life without pug is possible but pointless."
(Loriot: "Ein Leben ohne Mops ist moeglich, aber sinnlos.")


Have a nice day :)

Thomas

[Dan Purgert]

Post by Thomas Schmitt
Hi,

Post by t***@tuxteam.de
Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I
just retire before the alternatives aren't viable anymore. Or perhaps, as
with PulseAudio, I can leapfrog that "tech".

Retirement is no solution.
What shall we retirees do when X11 is laid to rest ?
I am not aware of anything like fvwm running on Wayland.

Use tty1 with screen/tmux? :D

[Jeffrey Walton]

Post by t***@tuxteam.de
[...]
(The most probable outcome though is even less rosy: everything'll run in
the browser, and Secure Boot will make sure that your hardware refuses to
run anything else, because the chips are sponsored by the Ad Industry.

Lol...

[Greg Wooledge]

Post by Greg Wooledge
Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward. Documentation would be my top priority. If other people want
to try to drum up interest in environment configuration, then there'll
be documentation available for end users to follow.

I've added a bit of content to <https://wiki.debian.org/EnvironmentVariables>.

I didn't mention dbus at all. If anyone knows about dbus configuration,
please feel free to add it, or to post something here on debian-user.

[Max Nikulin]

Post by Greg Wooledge

Post by Greg Wooledge
Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward. Documentation would be my top priority. If other people want
to try to drum up interest in environment configuration, then there'll
be documentation available for end users to follow.

I've added a bit of content to <https://wiki.debian.org/EnvironmentVariables>.

Isn't the following a more suitable article for umask?
<https://wiki.debian.org/Permissions#Setting_default_umask>
I think, it is better to drop UMask note from EnvironmentVariables.

[Greg Wooledge]

Post by Max Nikulin

Post by Greg Wooledge

Post by Greg Wooledge
Now we just need for GNOME users to discover a way to configure the
programs that are started as children of dbus, and then we can move
forward. Documentation would be my top priority. If other people want
to try to drum up interest in environment configuration, then there'll
be documentation available for end users to follow.

I've added a bit of content to <https://wiki.debian.org/EnvironmentVariables>.

Isn't the following a more suitable article for umask?
<https://wiki.debian.org/Permissions#Setting_default_umask>
I think, it is better to drop UMask note from EnvironmentVariables.

I've made some minor changes to both pages.

[Darac Marjal]

I'm not saying that what you did was wrong, but systemd provides a few
shortcuts which can make things a bit more user-friendly.

OK. Let's follow this path a bit.
I googled "how to create a systemd user service" and got
<https://blog.victormendonca.com/2018/05/14/creating-a-simple-systemd-user-service/>.
hobbit:~$ cd .config
hobbit:~/.config$ mkdir -p systemd/user
hobbit:~/.config$ vi systemd/user/xterm.service
hobbit:~/.config$ cat systemd/user/xterm.service
[Unit]
Description=Try to run an xterm
[Service]
Type=simple
StandardOutput=journal
ExecStart=/usr/bin/xterm
[Install]
WantedBy=default.target

I think the systemd shortcut here is "systemctl --user edit
xterm.service". Now, "systemctl edit" usually edits an "override" file
(allowing you to override settings supplied by the OS, you can edit the
service file directly by adding the "--full" option. And, if you are
creating a new service you tend to have to add "--force". So, the most
reliable command for editing a user command would be "systemctl --user
edit --force --full xterm.service".

One advantage of using "systemctl edit" rather than simply "$EDITOR" is
that "systemctl edit" will perform a daemon-reload upon exiting the
editor. That is, "systemctl edit" makes systemd aware of the changes.

hobbit:~/.config$ systemctl --user enable xterm.service
Created symlink /home/greg/.config/systemd/user/default.target.wants/xterm.service → /home/greg/.config/systemd/user/xterm.service.
hobbit:~/.config$ systemctl --user start xterm.service

You can combine "enable" and "start" into a single command by adding
"--now" to the enable command, thus: "systemctl --user enable --now
xterm.service".

[d***@howorth.org.uk]

Post by Darac Marjal
I'm not saying that what you did was wrong, but systemd provides a
few shortcuts which can make things a bit more user-friendly.

OK. Let's follow this path a bit.
I googled "how to create a systemd user service" and got
<https://blog.victormendonca.com/2018/05/14/creating-a-simple-systemd-user-service/>.
hobbit:~$ cd .config
hobbit:~/.config$ mkdir -p systemd/user
hobbit:~/.config$ vi systemd/user/xterm.service
hobbit:~/.config$ cat systemd/user/xterm.service
[Unit]
Description=Try to run an xterm
[Service]
Type=simple
StandardOutput=journal
ExecStart=/usr/bin/xterm
[Install]
WantedBy=default.target

I think the systemd shortcut here is "systemctl --user edit
xterm.service". Now, "systemctl edit" usually edits an "override"
file (allowing you to override settings supplied by the OS, you can
edit the service file directly by adding the "--full" option. And, if
you are creating a new service you tend to have to add "--force". So,
the most reliable command for editing a user command would be
"systemctl --user edit --force --full xterm.service".
One advantage of using "systemctl edit" rather than simply "$EDITOR"
is that "systemctl edit" will perform a daemon-reload upon exiting
the editor. That is, "systemctl edit" makes systemd aware of the
changes.

hobbit:~/.config$ systemctl --user enable xterm.service
Created
symlink /home/greg/.config/systemd/user/default.target.wants/xterm.service
→ /home/greg/.config/systemd/user/xterm.service. hobbit:~/.config$
systemctl --user start xterm.service

You can combine "enable" and "start" into a single command by adding
"--now" to the enable command, thus: "systemctl --user enable --now
xterm.service".

Increasingly systemd reminds me of SMIT (the system management part of
AIX). Designed to simplify complicated system management scripts by
using multiple short scripts, it just resulted in thousands and
thousands of system management scripts to manage :(

[Max Nikulin]

Post by Greg Wooledge
hobbit:~$ cat .config/systemd/user/service.d/env.conf
[Service]
Environment="FOO=%h/test123" "BAR=b a r"
hobbit:~$ systemctl --user daemon-reload
hobbit:~$ systemctl --user start xterm.service

daemon-reload is not enough in KDE. krunner and plasmashell services
have been started already, so changes would not apply despite they are
visible in "systemctl --user show-environment". Perhaps launchers just
do not listen for a proper D-Bus signal emitted by systemd user daemon.
The same applies for environment.d.

So logout is necessary.

I have unsuccessfully tried to find a way to apply environment.d without
logout. I do not see anything relevant in KDE system settings.
<https://userbase.kde.org/Session_Environment_Variables> suggests
$HOME/.config/plasma-workspace/env/path.sh that are autostart scripts,
so runtime changes are not applied.

SSH login may cause starting of some systemd user services:

948 pts/0 Ss 0:00 \_ -bash
1017 pts/0 R+ 0:00 \_ ps xwf
921 ? Ss 0:00 /lib/systemd/systemd --user
927 ? S 0:00 \_ (sd-pam)
942 ? Ssl 0:00 \_ /usr/bin/pulseaudio --daemonize=no
--log-target=journal
984 ? Ss 0:00 \_ /usr/bin/dbus-daemon --session
--address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

An additional consideration concerning applications started through
D-Bus: I think, they are started through systemd nowadays. At first I
forgot that enough .desktop files prescribe starting through D-Bus
ignoring Exec= field.

/usr/share/applications/org.kde.kwrite.desktop:X-DBUS-StartupType=Multi
/usr/share/applications/org.kde.kwrite.desktop:X-DBUS-ServiceName=org.kde.kwrite

[Franco Martelli]

Post by Greg Wooledge
I've added a bit of content to <https://wiki.debian.org/EnvironmentVariables>.
daemon-reload is not enough in KDE. krunner and plasmashell services
have been started already, so changes would not apply despite they are
visible in "systemctl --user show-environment". Perhaps launchers just
do not listen for a proper D-Bus signal emitted by systemd user daemon.
The same applies for environment.d.
So logout is necessary.

If you plan to add your contribute to the wiki page (see above) in the
section: "Desktop Environments and systemd user services" e.g.:

- ...
- systemctl --user daemon-reload
- /Restart your Desktop session/

Please consider also to specify the Desktop you use, because newbies
don't know nothing about: "Some Desktop Environments launch programs via
systemd user services." Which Desktop? IMO it's better to add /(like
KDE)/ and changing the statement in this way: "Some Desktop Environments
(like KDE) launch programs via systemd user services."

Just my 2¢ tips, thanks

[Greg Wooledge]

Post by Franco Martelli
If you plan to add your contribute to the wiki page (see above) in the
- ...
- systemctl --user daemon-reload
- /Restart your Desktop session/
Please consider also to specify the Desktop you use, because newbies don't
know nothing about: "Some Desktop Environments launch programs via systemd
user services." Which Desktop?

Well, that's the problem, isn't it? *We* don't know either, because
most of us don't use one!

I'm doing the best I can trying to document these systems that I don't
use personally. It would be *nice* if their developers would document
them, so we wouldn't have to reverse engineer how they work and come up
with our own workarounds. It's much, much harder when you can't even
reverse engineer one yourself, and instead have to rely on the reports
of other users.

[Nicolas George]

Post by Greg Wooledge
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?

This is very true. And alas, it is not limited to umask: environment
variables, limits, etc.

The solution I chose for myself is to put it in .zshenv, zsh being my
shell, and making sure all my other startup scripts are #!/bin/zsh. But
I am sure modern display managers manage to start modern desktop
environments that manage to run user applications without ever invoking
the login shell. Yay for modernity.

Anyway, this whole discussion is moot, because:

- Experienced users can find a solution for the specific system they
use.

- Even though the default umask is permissive, the permissions on ~ can
be restrictive, and for lusers it is functionally equivalent, and the
default permissions on ~ is asked by debconf.

Regards,

[Jeffrey Walton]

On Mon, Jul 15, 2024 at 12:06 PM Eduardo M KALINOWSKI

Post by Eduardo M KALINOWSKI

Dear list,
I am wondering, why on a multiuser system like debian the rights for a normal
user are "rw- r-- r--", (owner: user and ownergroup: usergroup)
Of course there is a reason for this, but it is not understandable for me.
First two are clear: rw for myself, and readable for all users, i am allowing
into my own grou.
The last one is not clear for me. Why should I allow the rest of the world
read my personal documents? These are private and no one else should be able
to read them!
So I would have expected a setting of "rw- r-- ---" for any files.
Before someone argues, "you can change this by editing umask", yes, I know of
this of course.
But it is not clear for me, why it is set that way by default and not as I
would have expected as described above.
Sure, there is a reason for this, so I will be happy, if someone could
enlighten me.

I kind of agree with that in principle, and I've always used an umask
077 myself.
On the other hand, I'm the only user in my system, so it doesn't really
matter. I expect that is the case for most users.
I'm not sure if the Debian default should be changed, though.

Debian is a multi-user operating system. Decisions should be made accordingly.

I suppose umask is a moot point on phones and tablets, where
single-user is often the use case.

Jeff

[Darac Marjal]

Post by Jeffrey Walton
Debian is a multi-user operating system. Decisions should be made accordingly.
I suppose umask is a moot point on phones and tablets, where
single-user is often the use case.

On the contrary, modern Android is strongly multi-user. Each "app" tends
to be allocated its own user ID. The logic is is to provide strong
isolation between apps.

Post by Jeffrey Walton
Jeff

[Tim Woodall]

Post by Jeffrey Walton
Debian is a multi-user operating system. Decisions should be made accordingly.
I suppose umask is a moot point on phones and tablets, where
single-user is often the use case.

umask 077 can come with its own problems when using shared directories.

years ago I used to use cvs pserver specifically to finesse this
problem. Now that (almost) everybody uses a remote git server it's less
relevant there.

I'm not a sudo user but IIUC, root inherits the umask, which can then
cause problems when things can't read config files that should be world
readable.

Rather than change umask, I'd suggest that the better change is to make
home directories 0700 by default. If that is the wrong choice then it
only has to be fixed once per user. Creating 'world/group' readable
files with too restrictive permissions never goes away.

[Max Nikulin]

Post by Tim Woodall
umask 077 can come with its own problems when using shared directories.

<https://wiki.debian.org/UserPrivateGroups>

Taking into account old 022 vs. 002 discussions it might be 007.

Post by Tim Woodall
I'm not a sudo user but IIUC, root inherits the umask, which can then
cause problems when things can't read config files that should be world
readable.

Do you mean the following bug or something else?
<https://bugs.debian.org/711104>
login: su - doesn't set umask
Fixed in version pam/1.5.3-1
Tue, 16 Jan 2024 00:19:23 +0000

Post by Tim Woodall
Rather than change umask, I'd suggest that the better change is to make
home directories 0700 by default.

The topic starter believes it is not enough
<https://lists.debian.org/msgid-search/***@protheus2>
Mon, 15 Jul 2024 09:04:54 +0200

However I would not mind to read more details what use cases are not
covered. /tmp?

[Greg Wooledge]

Post by Max Nikulin
Do you mean the following bug or something else?
<https://bugs.debian.org/711104>
login: su - doesn't set umask
Fixed in version pam/1.5.3-1
Tue, 16 Jan 2024 00:19:23 +0000

Huh... given the age of the bug, I expected this was something already
done in bookworm, but it's not.

hobbit:/etc/pam.d$ grep -i umask *
hobbit:/etc/pam.d$ grep -i mask *
hobbit:/etc/pam.d$

Bookworm has PAM package version 1.5.2-6+deb12u1, not 1.5.3. Looks like
this change was only made this year, and therefore won't appear until
Debian 13.

This makes me wonder what's setting umask *now*. Is it still PAM, just
using a compile-time default instead of a value that's discoverable in
a conffile?

Also, this confused me:

hobbit:/etc/pam.d$ dpkg -S /etc/pam.d/common-session
dpkg-query: no path found matching pattern /etc/pam.d/common-session

Where does that file come from, then? The installer? Oh wait, there are
postinst scripts....

hobbit:~$ grep common-session /var/lib/dpkg/info/*.postinst
/var/lib/dpkg/info/libpam-runtime.postinst: for configfile in common-auth common-account common-session \
/var/lib/dpkg/info/libpam-runtime.postinst: "$DPKG_ROOT"/etc/pam.d/common-session.pam-old

So I guess that file comes from libpam-runtime, but it's not managed
like a regular conffile. I suppose there was some reason for this, even
if I can't guess it.

[Max Nikulin]

Post by Greg Wooledge
hobbit:/etc/pam.d$ dpkg -S /etc/pam.d/common-session
dpkg-query: no path found matching pattern /etc/pam.d/common-session
Where does that file come from, then?
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.

The tool has a brief man page. Files in pam.d need update when packages
with pam modules are installed or removed. It seems similar to some
other config file only a part of it is managed by a tool.

Taking into account a number of bugs, perhaps it is not really bad that
recipes how to change umask are not easily available. Documentation
should be extensive enough to describe possible pitfalls.

[Greg Wooledge]

Post by Max Nikulin
Taking into account a number of bugs, perhaps it is not really bad that
recipes how to change umask are not easily available. Documentation should
be extensive enough to describe possible pitfalls.

That's an odd stance, especially if you consider that changing your umask
used to be literally a one-line change. It still is, if you only use
the shell (locally or remotely). It still is, if you use a shell login
plus startx plus a traditional window manager.

Even with a Display Manager login and a traditional WM, there are still
just two places you need to change.

It only becomes *hard* when Desktop Environments are introduced into the
picture.

[songbird]

Greg Wooledge wrote:
...

Post by Greg Wooledge
It only becomes *hard* when Desktop Environments are introduced into the
picture.

so far, agreed, i poked at it a bit the other day to see
if MATE would work with the roughly (user-@1000,etc) systemd
unit approach but that didn't accomplish anything i could tell.

no more time this week for such journeys and
exploritations... but i'll continue reading along as i get
time as the topic is interesting and convoluted which are
the best sort of puzzles. :)


songbird

[Max Nikulin]

Post by songbird
so far, agreed, i poked at it a bit the other day to see
unit approach but that didn't accomplish anything i could tell.

It would be great if those, who tried it, reported more precise what
they did.

- Did you call "systemctl daemon-reload" for *system* instance after
adding a drop-in for ***@1000.service?
- Did you do logout after in the case of *user* service.d override? It
is not enough to execute "systemd --user daemon-reload".
- Does MATE use scopes and services to run applications an components?
"ps xwf" and "systemd-cgls" trees may clarify where started applications
appear.

[songbird]

Post by Max Nikulin

Post by songbird
so far, agreed, i poked at it a bit the other day to see
unit approach but that didn't accomplish anything i could tell.

It would be great if those, who tried it, reported more precise what
they did.
- Did you call "systemctl daemon-reload" for *system* instance after
- Did you do logout after in the case of *user* service.d override? It
is not enough to execute "systemd --user daemon-reload".
- Does MATE use scopes and services to run applications an components?
"ps xwf" and "systemd-cgls" trees may clarify where started applications
appear.

neither of those show all the programs that i have
included on the panels, but there are cgroups and some
of the other programs listed.

the missing programs are indeed being started since i
use them all the time.


songbird

[Max Nikulin]

Post by songbird

Post by Max Nikulin
- Does MATE use scopes and services to run applications an components?
"ps xwf" and "systemd-cgls" trees may clarify where started applications
appear.

neither of those show all the programs that i have
included on the panels, but there are cgroups and some
of the other programs listed.

The question is what are parents of processes started from menus,
desktop icons, launchers, etc. in both trees. The special case is
flatpak/snap sandboxes.

Maybe you will find missed applications in output of "ps axuwf" and
"systemd-cgls" executed as root. Sometimes it is not easy to associate
process names and user friendly names used in desktop environment. You
may try to grep in /usr/share/applications for names and "Exec".

[Tim Woodall]

Post by Max Nikulin

Post by Tim Woodall
umask 077 can come with its own problems when using shared directories.

<https://wiki.debian.org/UserPrivateGroups>
Taking into account old 022 vs. 002 discussions it might be 007.

Post by Tim Woodall
I'm not a sudo user but IIUC, root inherits the umask, which can then
cause problems when things can't read config files that should be world
readable.

Do you mean the following bug or something else?

No, I'm talking about sudo, not su. I'm not a sudo user so I can't test
but my understanding is that root inherits the umask of the invoking
user (or it used to)

[Greg Wooledge]

Post by Tim Woodall
No, I'm talking about sudo, not su. I'm not a sudo user so I can't test
but my understanding is that root inherits the umask of the invoking
user (or it used to)

Looks like this is still true.

hobbit:~$ bash
hobbit:~$ umask 077
hobbit:~$ umask
0077
hobbit:~$ sudo -s
[sudo] password for greg:
***@hobbit:/home/greg# umask
0077
***@hobbit:/home/greg# exit
exit
hobbit:~$ sudo -i
***@hobbit:~# umask
0077
***@hobbit:~# exit
logout
hobbit:~$ sudo bash -c umask
0077
hobbit:~$ umask 022
hobbit:~$ sudo bash -c umask
0022

[Max Nikulin]

Post by Greg Wooledge

Post by Tim Woodall
No, I'm talking about sudo, not su. I'm not a sudo user so I can't test
but my understanding is that root inherits the umask of the invoking
user (or it used to)

Looks like this is still true.
hobbit:~$ umask 077

[...]

Post by Greg Wooledge
hobbit:~$ sudo bash -c umask
0077

Partially it is the same issue as with su when pam_umask.so is missed in
common-session. When it is present, the value from login.defs is
respected for "sudo -i". However I am in doubts if it is proper
behavior. For administrative tasks 022 is more reasonable default even
if something else is configured for regular users.

sudoers(5) describes "umask_override" and "umask" settings. It seems
changing default umask requires modification of these preferences.