sacham...@s0c4.net wrote in
<20200728180323.GE15493@lucid>:
|The thread, and even older threads referenced there, is from 2007. \
|Since then, the security field have evolved - now we have SeLinux, \
|Apparmor and other techniques which are capable to provide even better \
|security than umask(077) - I would say that ignoring shell's umask \
|and enforcing our own may be actually harmful in above mentioned contexts.
|
|Please don't take me wrong - I fully agree on default of 0600 for all \
|created files (undoubtely mboxes). Yet even in my simple scenario (mutt \
|got its own user profile) I need to be able to process stored attachments \
|by other users (separate user for libreoffice, separate user for image \
|viewer,...). Manually calling chmod *each and every time* is even more \
|security-error-prone than being able to set umask once for time being.
|>
|We may even make this patch available only as by default disabled config\
|ure option, I can imagine something like --enable-umask-override. How \
|does that differ from applying my patch manually? Simply one does not \
|have to trust "random patch from the internet", but supported option \
|available for users who know what/why they want.
fwiw, for the MUA i maintain i implemented an umask override:
umask
For a safe-by-default policy the process file mode creation mask
umask(2)[762] will be set to ‘0077’ on program startup after the
resource files have been loaded, and unless this variable is set.
By assigning this an empty value the active setting will not be
changed, otherwise the given value will be made the new file mode
creation mask. Child processes inherit the file mode creation mask
of their parent.
? xv var umask
#nodelete,initial-value,positive-number
set umask=''
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
