[sf-lug] root and umask value ... and temporary and ...

[Michael Paoli]

> From: "Daniel Gimpelevich" <daniel at gimpelevich.san-francisco.ca.us>
> Subject: Re: [sf-lug] root and umask value :-)
> Date: Sun, 01 Jan 2017 18:32:32 -0800

> On Sun, 2017-01-01 at 18:26 -0800, Michael Paoli wrote:
>> session - in temporary location - may well and often be /tmp
>> or /var/tmp

> Would it not suffice to just cd into a 0700 directory before doing that?

Yes, and no.  For stuff that's intended to be temporary, better to  
have that in
a location that's well known to be temporary ... and also generally cleaned of
old cruft on a fairly regular basis.  Otherwise there's often the issue of
trying to figure out what is old cruft that was intended to be  
temporary and is
safe to remove.  And I can, and sometimes do, create a mode 700 directory
under /tmp or /var/tmp ... most notably when dealing with some fair number of
files that are intended to be temporary.  Of course then, umask 022  
doesn't 100%
cover it in that case - e.g. if one hard links file to a location not  
so protected,
or if some command(s) one may run may not so protect their files (e.g.  
temporary files).

And when I'm to the point where there's data to be preserved longer -  
it will get
moved/copied to more suitable location for longer term storage.  Also,  
temporary
locations may commonly be better optimized for higher I/O performance  
- that's often
what's desired when initially working with such a temporary data set - and in
some/many case may, e.g., saves lots of physical storage I/O  
operations (e.g. tmpfs).
Of course there may be other considerations too - e.g. if the system  
reboots or
crashes, do I particularly care if that data persists through such, and which
filesystem(s) have ample free space for dealing with the intended data to be
worked with.

And, when there's need to temporarily store something elsewhere,
I'll generally have/put in place something to clean it up later (e.g.
at job to remove the file 95 days hence if, at that time, it's still there
and has an mtime more than 90 days old).  E.g. ;-) ...
I really don't want to see some huge collection of older configuration files
bloating a configuration file directory - that's what version control  
and backups
are for ... and if folks can't do version control, or that's not the  
convention
there, at least have it reasonably cleaned up.  Most of the time, a  
configuration
change done more than 90 days ago won't be of interest - and if it may  
likely have
been important, it should be in version control and/or backups, or  
otherwise reasonably
tracked and such.  Most of the time, what's current, and occasionally  
handy access to
a prior version or two might be useful.  But often more important to  
easily see what's
currently active, and not be distracted by a plethora of old versions  
sticking about
that aren't active - and may make it more probable one otherwise  
misses some important
detail of what *is* active, relevant, and in use.  Not to mention  
time/efficiency in
being able to see/find what is almost always of most importance and relevance.