[sf-lug] root and umask value :-)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] What purpose is served by the first two parts?  
> (cd / && umask 022	...
> Date: Sun, 1 Jan 2017 14:17:26 -0800

> Moreover, root should already have:
>
> # umask
> 0022
> # If something's setting root's umask to something else, then d00d, you're
> doin' it wrong.  ;->

Well ... ;-)
umask values of 022, or 077, or sometimes even 027, may be reasonable
for superuser ("root").

Does depend on context.

First of all, generally best not to alter the default, particularly for
anything other than one's own personal system where nobody else will
ever administer it, nor be asked to assist on sorting out whatever mess
one may have created.  Principle of Least Surprise 'n all that.

And if the admin duties are shared, again, best not to muck with that
default, unless all are highly aware of it and willing to take on the
potential issues.

But :-) ... as far as an interactive root login session, fine to
change/set it to something reasonable - as long as one remains
sufficiently aware of it.  And I'm *not* talking about putting it in
~root/.profile or the like.
E.g., in my typical root interactive login sessions, I generally change
the umask value to 077 - but then I'll use 022 anytime I'm
installing/removing/upgrading software, shutting down, etc., where I
presume most of that software and logs will be sufficiently protected by
022 umask permissions, and anything that ought be more tightly protected
is probably so protected by the applicable software itself or its
configuration thereof.  So, why do or would I typically do this?  Mostly
security - specifically prevention of accidental leakage of information.
Not too infrequently I'll have to go through lots of data, some of which
does or may contain information which shouldn't be world readable.  A
typical example, I'm tasked to investigate a yet unexplained anomaly
that occurred around such-and-such time.  I may open up a scratch vi(1)
session - in temporary location - may well and often be /tmp or /var/tmp
(typically invoking vi(1) without options).  If I were to do that
unthinkingly with umask 022, then that data - e.g. scratch/temporary
vi(1) file, would be world readable - and I may well be pulling in data
which should only be readable by root.  I may then proceed to pull in
lots of data which may be relevant - toss out lots of data that's
uninteresting/irrelevant and ... see if maybe I end up left with the
"smoking gun"* ... or not.  Anyway, the potential tradeoffs/risks -
notably with root using umask 077, is making something(s) too secure /
inaccessible.  And with 022, of potentially exposing what shouldn't be
exposed (e.g. sometimes I may examine shadow file data - notably to
inspect which hash algorithms used when password was last changed - some
operating systems don't provide the tools to get that detailed of
specific data from shadow files - and even for those that do, at least
some of that data would generally be considered root access only
(notably which hash algorithms were used on which accounts)).  Ugh ...
and really prefer not to need to look through history file of accounts
... but sometimes needed to in order to figure out who (or which
account) done it, and if it appears to be incompetence, accident, or
malicious.  Filtering by things like time (was the account active at the
time) and strings/REs of potential relevance can help avoid lookin' at
stuff I really don't want to see anyway.

Anyway, regardless of umask value - be it 022, or 077, when operating as
superuser ("root"), be aware of umask value and the context in which one
is operating (e.g. installing/configuring stuff that's for general
access, or examining what does or may contain data that should not be
world readable on the host).

*some smoking guns found, e.g.:
- reboot not explained ... [r]syslogd was SIGTERMed ... reboot was
   issued ... [expletives deleted] 3rd party binary closed source [lots
   more expletives deleted] has [ditto] "recovery" <cough, cough>
   functionality, where if its own software doesn't respond "fast
   enough" it [ditto] executes reboot - as root ... and the [ditto]
   software runs as root!  (Lots more wrong with that [ditto] software -
   but that's just yet another typical example.)
- a more jr. admin from another area asks for assistance on finding
   cause of "unexplained" reboot ... they weren't able to find cause ...
   reboot command was issued as root ... root gotten to via sudo ...
   from the ID of that jr. admin ... over ssh, from ... okay, I didn't
   have access to the system of that source IP, but I was able to provide
   IP (and maybe also source port) that sshed into the host and time of
   that connection information, and when it sudoed to root, and when it
   rebooted the host.  (and was someone else's job to take it further
   from that point).