Re: umask - default user settings?

[Max Nikulin]

On 18/07/2024 00:01, Greg Wooledge wrote:

On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote:

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

[...]

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.

Re: umask - default user settings?

[Max Nikulin]

On 19/07/2024 10:45, songbird wrote:

- 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".

Re: umask - default user settings?

[Greg Wooledge]

On Fri, Jul 19, 2024 at 23:04:25 +0700, Max Nikulin wrote:
> On 16/07/2024 20:46, Greg Wooledge wrote:
> > On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:
> > > 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 
> > .
> 
> Isn't the following a more suitable article for umask?
> 
> I think, it is better to drop UMask note from EnvironmentVariables.

I've made some minor changes to both pages.

Re: umask - default user settings?

[Max Nikulin]

On 16/07/2024 20:46, Greg Wooledge wrote:

On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:

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 .


Isn't the following a more suitable article for umask?

I think, it is better to drop UMask note from EnvironmentVariables.

Re: umask - default user settings?

[songbird]

Max Nikulin wrote:
> On 19/07/2024 04:11, songbird wrote:
>>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.
>
> 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 user@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.

  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

Re: umask - default user settings?

[Max Nikulin]

On 19/07/2024 04:11, songbird wrote:

   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.


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 user@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.

Re: umask - default user settings?

[songbird]

Greg Wooledge wrote:
...
> 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

Re: umask - default user settings?

[Greg Wooledge]

On Thu, Jul 18, 2024 at 09:07:48 +0700, Max Nikulin wrote:
> 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.

Re: umask - default user settings?

[Max Nikulin]

On 17/07/2024 22:40, Greg Wooledge wrote:

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?


This file contains the following:


# 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.

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 20:51:40 +0200, Franco Martelli wrote:
> 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?

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.

Re: umask - default user settings?

[Franco Martelli]

On 16/07/24 at 15:46, Greg Wooledge wrote:

I've added a bit of content to .



On 17/07/24 at 04:37, Max Nikulin wrote:
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
--
Franco Martelli

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote:
> 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: 
root@hobbit:/home/greg# umask
0077
root@hobbit:/home/greg# exit
exit
hobbit:~$ sudo -i
root@hobbit:~# umask
0077
root@hobbit:~# exit
logout
hobbit:~$ sudo bash -c umask
0077
hobbit:~$ umask 022
hobbit:~$ sudo bash -c umask
0022

Re: umask - default user settings?

[Tim Woodall]

On Wed, 17 Jul 2024, Max Nikulin wrote:


On 17/07/2024 15:37, Tim Woodall wrote:

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




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


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)

Re: umask - default user settings?

[Max Nikulin]

On 15/07/2024 09:15, Alan D. Salewski wrote:
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:



     # 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



Have you tried to change it?



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 +

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

Re: umask - default user settings?

[Greg Wooledge]

On Wed, Jul 17, 2024 at 22:10:28 +0700, Max Nikulin wrote:
> Do you mean the following bug or something else?
> 
> login: su - doesn't set umask
> Fixed in version pam/1.5.3-1
> Tue, 16 Jan 2024 00:19:23 +

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.

Re: umask - default user settings?

[Max Nikulin]

On 17/07/2024 15:37, Tim Woodall wrote:

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




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


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?

login: su - doesn't set umask
Fixed in version pam/1.5.3-1
Tue, 16 Jan 2024 00:19:23 +


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

Mon, 15 Jul 2024 09:04:54 +0200

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

Re: umask - default user settings?

[Tim Woodall]

On Mon, 15 Jul 2024, Jeffrey Walton wrote:



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.

Re: umask - default user settings?

[Max Nikulin]

On 16/07/2024 10:39, Greg Wooledge wrote:

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. 
 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/0Ss 0:00  \_ -bash
   1017 pts/0R+ 0:00  \_ ps xwf
921 ?Ss 0:00 /lib/systemd/systemd --user
927 ?S  0:00  \_ (sd-pam)
942 ?Ssl0: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

Re: umask - default user settings?

[Dan Purgert]

On Jul 16, 2024, Thomas Schmitt wrote:
> Hi,
> 
> to...@tuxteam.de wrote:
> > 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

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: umask - default user settings?

[debian-user]

Darac Marjal  wrote:
> 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.
> 
> On 16/07/2024 04:39, Greg Wooledge wrote:
> > OK. Let's follow this path a bit.
> > I googled "how to create a systemd user service" and got
> > .
> >
> > 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  
> 
> 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 :(

Re: umask - default user settings?

[Darac Marjal]

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.


Jeff



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: umask - default user settings?

[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.


On 16/07/2024 04:39, Greg Wooledge wrote:

OK. Let's follow this path a bit.
I googled "how to create a systemd user service" and got
.

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


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".




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: umask - default user settings?

[Jeffrey Walton]

On Tue, Jul 16, 2024 at 1:45 PM  wrote:
>[...]
>
> (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...

Re: umask - default user settings?

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> 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.


> (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 ?


> 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

Re: umask - default user settings?

[tomas]

On Tue, Jul 16, 2024 at 11:52:29AM -0400, Greg Wooledge wrote:
> On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote:
> > 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.

[...]

> 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
-- 
t


signature.asc
Description: PGP signature

Re: umask - default user settings?

[Greg Wooledge]

On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote:
> 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.

Re: umask - default user settings?

[Max Nikulin]

On 16/07/2024 19:03, Greg Wooledge wrote:

On Tue, Jul 16, 2024 at 18:42:40 +0700, Max Nikulin wrote:

On 16/07/2024 10:39, Greg Wooledge wrote:

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

from 2013 briefly discussing 022 vs. 002 values.

Re: umask - default user settings?

[Greg Wooledge]

On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote:
> 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 .

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.

Re: umask - default user settings?

[Greg Wooledge]

On Tue, Jul 16, 2024 at 18:42:40 +0700, Max Nikulin wrote:
> On 16/07/2024 10:39, Greg Wooledge wrote:
> > 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.

> > 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.

Re: umask - default user settings?

[Max Nikulin]

On 16/07/2024 10:39, Greg Wooledge wrote:

On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote:

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


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)
│   ├─user@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


systemd --user process inherits my $DISPLAY


You may use

systemctl --user show-environment


[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.



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.




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.


systemd.unit(5):

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,


Greg Wooledge wrote:

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.

Re: umask - default user settings?

[Nicolas George]

Greg Wooledge (12024-07-15):
> 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,

-- 
  Nicolas George

Re: umask - default user settings?

[Greg Wooledge]

On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote:
> I have naively tried
> 
> cat ~/.config/systemd/user/service.d/umask.conf
> [Service]
> UMask=0007
> 
> From xterm and konsole:
> 
> umask
> 0007

OK.  Let's follow this path a bit.

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

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.

Re: umask - default user settings?

[Max Nikulin]

On 16/07/2024 08:34, Greg Wooledge wrote:

On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote:


systemd.exec(5)


UMask=

[...]

[5] refers to .


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.



https://github.com/systemd/systemd/issues/16963#issuecomment-689656886

mkdir -p /etc/systemd/system/user@1000.service.d
cat >  /etc/systemd/system/user@1000.service.d/umask.conf<

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.

Re: umask - default user settings?

[Jeffrey Walton]

On Mon, Jul 15, 2024 at 9:34 PM Greg Wooledge  wrote:
>
> On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote:
> [...]
> > 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 .
>
> 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.

++

When I read that, I tried it myself:

root@raptor:~# grep -IR 'jwalton@.service' /etc
root@raptor:~# grep -IR 'jwalton@.service' /lib
root@raptor:~#

> I can't find anything concrete in there.  Just a bunch of jabber.

Welcome to the world according to Pottering.

> 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

Re: umask - default user settings?

[Greg Wooledge]

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 .

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< > [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*?

Re: umask - default user settings?

[Max Nikulin]

On 15/07/2024 20:03, Greg Wooledge wrote:

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)


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).


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<

Re: umask - default user settings?

[Max Nikulin]

On 15/07/2024 01:10, Greg Wooledge wrote:

On Sun, Jul 14, 2024 at 19:57:45 +0200, to...@tuxteam.de wrote:

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

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.

Re: umask - default user settings?

[Jeffrey Walton]

On Mon, Jul 15, 2024 at 12:06 PM Eduardo M KALINOWSKI
 wrote:
>
> On 14/07/2024 14:09, Hans wrote:
> > 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

Re: umask - default user settings?

[Franco Martelli]

On 14/07/24 at 20:44, to...@tuxteam.de wrote:

  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
--
Franco Martelli

Re: umask - default user settings?

[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.

Re: umask - default user settings?

[Lists]

On 2024-07-15 14:30, Eduardo M KALINOWSKI wrote:


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

Re: umask - default user settings?

[Eduardo M KALINOWSKI]

On 14/07/2024 14:09, Hans wrote:

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.

--
Actually, my goal is to have a sandwich named after me.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: umask - default user settings?

[Greg Wooledge]

On Mon, Jul 15, 2024 at 09:04:54 +0200, Hans wrote:
> Also, when some other applicatiions are setting correct rights. 
> Some do, some don't. 

File bug reports against the ones which don't.

Re: umask - default user settings?

[Hans]

> 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
 

 

Re: umask - default user settings?

[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
#

-- 
underground experts united
https://dataswamp.org/~incal

Re: umask - default user settings?

[Alan D. Salewski]

On 2024-07-14 22:15:34, "Alan D. Salewski"  spake thus:
[...]

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/

Re: umask - default user settings?

[Greg Wooledge]

On Sun, Jul 14, 2024 at 22:15:34 -0400, Alan D. Salewski wrote:
> 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.

Re: umask - default user settings?

[Alan D. Salewski]

On 2024-07-14 19:38:26, Hans  spake thus:

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:



# 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




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.




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

--
a l a n   d.   s a l e w s k i
ads@salewski.email
salew...@att.net
https://github.com/salewski

Re: umask - default user settings?

[Max Nikulin]

On 15/07/2024 01:32, Hans wrote:

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.

Re: umask - default user settings?

[tomas]

On Sun, Jul 14, 2024 at 08:31:23PM +0200, Me wrote:
> On 2024-07-14 19:57, to...@tuxteam.de wrote:

[...]

> > [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
-- 
t


signature.asc
Description: PGP signature

Re: umask - default user settings?

[Me]

On 2024-07-14 19:57, to...@tuxteam.de wrote:

On Sun, Jul 14, 2024 at 07:44:35PM +0200, Lists wrote:

On 2024-07-14 19:18, Greg Wooledge wrote:

On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:

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

Re: umask - default user settings?

[Lists]

On 2024-07-14 19:43, Me wrote:

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

Re: umask - default user settings?

[tomas]

On Sun, Jul 14, 2024 at 02:10:46PM -0400, Greg Wooledge wrote:
> On Sun, Jul 14, 2024 at 19:57:45 +0200, to...@tuxteam.de wrote:

[...]

> 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.

>  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.

>  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
-- 
t


signature.asc
Description: PGP signature

Re: umask - default user settings?

[Me]

On 2024-07-14 19:18, Greg Wooledge wrote:

On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:

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

Re: umask - default user settings?

[Teemu Likonen]

* 2024-07-14 19:44:35+0200, li...@nodatagrabbing.com wrote:

> 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 user@.service unit. So, perhaps like this:

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

[Service]
UMask=0007

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: umask - default user settings?

[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

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

Re: umask - default user settings?

[Greg Wooledge]

On Sun, Jul 14, 2024 at 19:57:45 +0200, to...@tuxteam.de wrote:
> On Sun, Jul 14, 2024 at 07:44:35PM +0200, Lists wrote:
> > 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.

Re: umask - default user settings?

[Nicolas George]

Hans (12024-07-14):
> 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,

-- 
  Nicolas George

Re: umask - default user settings?

[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


> 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.

Re: umask - default user settings?

[Thomas Schmitt]

Hi,

Hans wrote:
> 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

Re: umask - default user settings?

[tomas]

On Sun, Jul 14, 2024 at 07:44:35PM +0200, Lists wrote:
> On 2024-07-14 19:18, Greg Wooledge wrote:
> > On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:
> > > 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 
-- 
t


signature.asc
Description: PGP signature

Re: umask - default user settings?

[Greg Wooledge]

On Sun, Jul 14, 2024 at 19:44:35 +0200, Lists wrote:
> 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.

Re: umask - default user settings?

[Greg Wooledge]

On Sun, Jul 14, 2024 at 19:38:26 +0200, Hans wrote:
> 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.

Re: umask - default user settings?

[Lists]

On 2024-07-14 19:18, Greg Wooledge wrote:

On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:

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

Re: umask - default user settings?

[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

Am Sonntag, 14. Juli 2024, 19:18:07 CEST schrieb Greg Wooledge:
> On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:
> > 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.

Re: umask - default user settings?

[Greg Wooledge]

On Sun, Jul 14, 2024 at 19:09:54 +0200, Hans wrote:
> 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.

umask - default user settings?

[Hans]

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.

Best

Hans