Bug#1065806: pam: recent upgrade changes previous default umask
Good Day,
I also noticed this change recently, and found it jarring, albeit mostly
cosmetic. The notes in /etc/login.defs do imply that it is up to
administrators, who we know have differing opinions on all matters of
topics. For example, I would like to keep the old USERGROUPS_ENAB set
to "yes", *and* to have a default umask of 022 (for reasons; even if
that does not make a lick of sense). Also, I often do have multiple
users on my systems who belong to a single group (something like
"users").
I remember posting on systemd @ github about how they were choosing to
handle, or not handle values in /etc/login.defs--or, maybe something
else semi-related--at a time in ancient history. The details, I do not
recall. But, I do not blame, nor believe, the systemd project has
anything to do with this particular change. Please correct me, if I am
wrong! And, maybe I can even be convinced that one handling of umasks
is better than...
Here is how I am handling it now...
In the default .bashrc for *root*, ever since I can remember, I have had
a configuration line commented out, which allows setting the umask value
to 022 for root. This is how it still behaves by default anyway, as
stated above. However, I am thinking to go ahead and...
I prefer the way it is handled per user. There is a related, commented
out, option in /etc/skel/.profile, which lands in new user directories,
which I have never touched the umask part until now. I uncommented the
line to set the users' default umask settings to 022 and updated users
already on the system.
At your own risk, if you follow along further :)
It was fun to see and reset the permissions on files since the change,
with:
~$ find . -type f -perm 664
and, upon confirming these are (mostly) the new files that I would have
preferred to have different permissions (as before), reset them all
with:
~$ find . -type f -perm 664 -execdir chmod 644 '{}' '+'
(Note: wireplumber keeps some state files in my home folders at 664,
which I guess is just the way they want it. Some other programs may
prefer different permissions and reset them, also. We will see!)
So far, I have not inspected, nor determined, whether directory
permissions were affected in a way I might find jarring.
Lastly, I already have .bash_profile and .xsessionrc doing little else
than 'sourcing' .profile and setting a few variables where appropriate.
I don't SSH into the box very often, so I am unsure if the umask holds
in various other situations.
Just my two cents,
Professor Jeebs
Bug#1061595: Debian Live 12.4.0 AMD64 Xfce Fails to Start Its Graphical Environment
Thank you Johnathan / Steve, It is working. Please feel free to close the bug report! Turns out that it was either failing hardware (an old-ish HP laptop I am becoming acquainted with for a family member), or more likely a failing USB stick, with the definite possibility of a mix of both, though the RAM in here seems fine :) Your suggestions were perfect. This is why I love Debian and its community. Technical excellence, and friendly-quick non-AI responses. I admit I had already tried the suggestions, then wrote the bug report from memory later that night. Please excuse the minor typos. Summary of what was done, if it may help another person in the future: After writing, `sync`. Then, `udisks2 power-off --block-device `. And, even, replugging the stick, checking `head -c | sha512sum`, just to make sure it matched the signed and verified checksum of the Debian Live Xfce image that was originally downloaded. All of that checked out perfectly. So, it did throw me off with the weird results I was observing. Besides the fail-safe kernel panic, I was also occasionally receiving squashfs errors that went previously unmentioned. Whatever was, or is, wrong seems to be on my end. More: USB stick is a 16GB MOSDART, and instead of simply zeroing out its original contents, I ran a `shred -n 1 /dev/xxx` on it... I know. Bad for a solid state medium. I also have had no previous experience with this brand. I am reasonably sure the problem has nothing to do with the brand of pendrive, but compatibility can be a funny thing sometimes. Thanks Again, Professor Jeebs
Bug#1061595: Debian Live 12.4.0 AMD64 Xfce Fails to Start Its Graphical Environment
Package: debian-live Severity: important X-Debbugs-Cc: je...@tuta.io Dear Debian Live Maintainers, Today, I have attempted to boot debian-live-12.4.0-amd64-xfce.iso, after `dd`ing it to a USB stick, and I failed miserably :( Grub functioned without any problems, and the Live Environment booted. However, the lightdm.service encountered errors, I believe to be related to the package accountservices perhaps not being installed (I neglected to check). It appears to be a mere suggested package in the log at link [1], where maybe another package in the system should instead be marked to depend or recommend the accountservices package--That, or perhaps it should be manually installed. An X display attempted to take over tty7, recurring in a loop, but then eventually failed, and the output of `systemctl status lightdm.server` gave more information pointing to accountservices, as in link [2]. Plain `startxfce` and `startx` did not do the trick either. I was out of ideas. Aside from that, I was able to change to tty[1-6]s and browse some logs, and perhaps could have ended up with a working system using the wireless-tools package. However, at this point, I was not connected to any networks (on purpose). .xsession-errors were spewed out, but Xorg logs did not note anything strange (no lines with EE, indicating errors, and maybe one or two WW which appeared unrelated to the problem at-hand). [1] https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.4.0-amd64-xfce.iso.log [2] https://bbs.archlinux.org/viewtopic.php?id=186550 Is this happening on your machines? Thanks! If this is a simple package installation to fix, I hope it can be out before the next dot-release. Debian rocks, as always :) A little more information: UEFI, Secure Boot enabled. Oddly, booting in failsafe mode, the kernel encountered a panic! I did not note it nor troubleshoot it any further. I almost chalked it up to a bad USB pendrive. The debian-live-12.4.0-amd64-cinnamon.iso, `dd`d in the same manner as the xfce version, booted up its graphical environment without any issues, therefor I believe I can rule out the pendrive being bad. I may be able to help troubleshoot this some more if it can not be triaged / reproduced. Just let me know!
