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)
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.
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.
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.
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.
Greg, I do not agree. If I am writing a document with private content, then I
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.
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)
First two are clear: rw for myself, and readable for all users, i am
allowing into my own grou.
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.
If you are writing something confidential, it is your responsibility to
lock the door of your office.
Regards,
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.
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
On Sun, Jul 14, 2024 at 19:57:45 +0200, [email protected] wrote:
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.
On 2024-07-14 19:57, [email protected] 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.
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
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
As it is, it
looks[1] like default perms for $HOME are 0755.
The user's umask value would matter less if the default perms of
user $HOME directories were 077
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.
Also, when some other applicatiions are setting correct rights.
Some do, some don't.
I'm not sure if the Debian default should be changed, though.
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 am not convinced that default umask should be changed)
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
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 [email protected] 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 [email protected] 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/[email protected]e.d
cat > /etc/systemd/system/[email protected]e.d/umask.conf<<EOF
[Service]
UMask=0007
EOF
systemctl daemon-reload
I have naively tried
cat ~/.config/systemd/user/service.d/umask.conf
[Service]
UMask=0007
From xterm and konsole:
umask
0007
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 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
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.
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.
Greg, do you have an example when Environment= in service.d works, but an environment.d file does not?
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.
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.
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 <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
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".
Hi,
[email protected] 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.
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.
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
On 17/07/2024 15:37, Tim Woodall wrote:
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.
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)
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?
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.
It only becomes *hard* when Desktop Environments are introduced into the picture.
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 [email protected]e?
- 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.
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 <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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:10:50 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,975 |