The reason (the only reason, as far as I know) to put users in a group of their own is to make umask 002
or umask 007
a sensible default.
The umask is a mask for the default permissions of newly created files. The meaning of the digits are the same as in chmod
; the first digit is for the user, the second for the group, and the third for others. If a bit is 1 in the umask, it is removed (masked) from the permissions of the newly created file. For example, if an application creates a non-executable file with no particular privacy requirement¹, it will pass 666 as the file permissions, and the application of the umask 002 will result in a file with permissions 664 (0666 & ~002
in C-like notation), i.e. a file which is readable by everyone and writable only by the user and group (rw-rw-r--
).
With the umask 022, files are world-readable by default but only writable by their author. With the umask 002, files are additionally writable by the group that owns them. If users's primary group is one where they are the only user, and the umask is 002, then:
- By default, files are only writable by their author, because although the permissions are
rw-rw-r--
, there is no other user in the group that has write permissions.
- To allow a file to be modified by members of a group, the author only needs to make it owned by that group with
chgrp
. This can even happen automatically if the file is created in a directory with the setgid bit or an equivalent ACL.
The advantage over the 022 umask is that in that setting, in order to make a file editable by users, the author must do two things: set the group, and extend the permissions (chmod g+w
). People tend to forget this second step (or sole step, in a setgid directory).
¹ Examples of files with particular privacy requirements: encryption keys; emails; any file in a public directory such as /tmp
.
For me, the xautolock process was still running in the background, but it wasn't listening to any xautolock -locknow
commands. As mentioned by @jrm, an application must be suppressing the "screensaver". For both of us, this was due to mpv (video player) disabling the screensaver.
For mpv, the fix is to add the following to ~/.config/mpv/config
or ~/.mpv/config
:
stop-screensaver=no
If you do not use mpv, it might be another application disabling the screensaver. Try some commonly used ones out to see which one it is.
If you want to prevent automatic screen locking during video playback, one common way is to use xautolock's "corners" feature:
xautolock -corners 000- -cornersize 30
With the above command, if you put your mouse cursor in the bottom right corner of the screen (within a 30px radius), auto-locking will be temporarily disabled.
One more thing to try is the -resetsaver
option:
xautolock -resetsaver
Or the -detectsleep
option:
xautolock -detectsleep
Best Answer
This is a security risk because file ownership in the FS is stored not by symbolic name, but by UID and GID. If a user is removed and files remain owned by that user, they become inaccessible under owner permission. However, if a different user is later created that is allocated the same UID, that user will gain ownership of the files. This is potentially a security risk because of the various ways in which file ownership is used as a security mechanism; the simplest form is that where confidential information (e.g. SSH keys in
id_rsa
and so forth, wi-fi authentication information inwpa_supplicant.conf
) could be leaked to the new user.