Hi Clint,
Clint Pachl wrote on Fri, Jan 26, 2018 at 10:43:47AM -0700:
> I received the following output from security(8):
>
> Running security(8):
> Can't
> opendir(/home/pachl/.cache/mozilla/seamonkey/e8cxa4g0.default/safebrowsing-backup):
> No such file or directory at /usr/libexec/security line 594.
>
> I didn't realize security parses through user files; beyond a few dot
> files.
It does so to find SUID/SGID files and special files, see the
function find_special_files().
Messages like the one you encountered are rare, and it would be hard
to suppress them without introducing a risk to hide actual problems.
> I don't understand perl. Is the script keeping state somewhere?
Yes, in /var/backups/{setuid,device}.{current,backup}, see the
function check_filelist() for details.
I just looked at what we wrote in the security(8) manual.
In the DESCRIPTION, we say:
* Check for changes in setuid/setgid files and devices.
* Check for changes in the device file list.
Below FILES, /var/backups is listed, without any further details.
I guess the documentation is good enough. As a rule, users are not
required to worry about the details of the algorithm or bookkeeping,
the script is supposed to just work and speak up if it notices anything
fishy. If somebody is curious, they can inspect the code, it is not
very long.
> How did it know to even try opening the safebrowsing-backup directory?
It looks everywhere because dangerous special files might hide anywhere.
It uses File::Find(3p) to do so.
Arguably, part of these checks have become less important since
we are mounting /home/ and other directories nodev and nosuid
by default. Then again, finding weird files in weird places is
still weird and should maybe still be noted. In any case,
restricting the search would complicate matters and increase the
risk of missing something relevant.
> The missing directory isn't listed in /etc/changelist or
> /etc/mtree/{special,*.secure}. I couldn't find any trace of it in /var/.
>
> So I manually ran the security script again. It returned no output.
The file of the name you quote above probably was a dead symbolic
link; it may only have existed for a short time, for example while
your browser was shuffling stuff around. Your seamonkey likely
removed it before your manual run - programs are kind of expected
to create and delete files in their own cache directories.
> I'm confused.
> Can anyone explain this?
I tried, with a bit of guessing.
Yours,
Ingo
