Bug#1065806: pam: recent upgrade changes previous default umask

2024-04-08 Thread Sam Hartman
control: clone -1 -2 control: retitle -2 Document pam_umask change in release notes

Bug#1065806: pam: recent upgrade changes previous default umask

2024-04-08 Thread Sven Joachim
On 2024-04-08 14:13 -0600, Sam Hartman wrote: >> "Professor" == Professor Jeebs writes: > > > Professor> I prefer the way it is handled per user.  There is a related, > commented > Professor> out, option in /etc/skel/.profile, which lands in new user > directories, > Professor>

Bug#1065806: pam: recent upgrade changes previous default umask

2024-04-08 Thread Sam Hartman
> "Professor" == Professor Jeebs writes: Professor> I prefer the way it is handled per user.  There is a related, commented Professor> out, option in /etc/skel/.profile, which lands in new user directories, Professor> which I have never touched the umask part until now.  I

Bug#1065806: pam: recent upgrade changes previous default umask

2024-03-14 Thread Professor Jeebs
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

Bug#1065806: pam: recent upgrade changes previous default umask

2024-03-12 Thread Antoine Le Gonidec
The change of behaviour can have an unexpected and quite nasty side-effect, by applying a misconfiguration that was ignored until this update. A setting of "UMASK 077" in /etc/login.defs was ignored before this update, and is now applied (as it should) leading to unreadable files if the user is

Bug#1065806: pam: recent upgrade changes previous default umask

2024-03-09 Thread Christoph Anton Mitterer
Source: pam Version: 1.5.3-6 Severity: normal Hey. Somwhere in between 1.5.2-9.1+b1 and 1.5.3-6 the default umask for non-root users has changed from 0022 to 0002. Interestingly, root doesn't seem to be affected. Intially I suspected b01196659c785b04abc387d324fae61e2ec3b1aa, but at least when