[balug-talk] updatedb: can not change group of file

[Michael Paoli]

Well, I don't have version of updatedb at my fingertips that supports
the
-l, --require-visibility IFLAG
option, but based on the description, I would guestimate that not
using the default value of 1 could be a security issue.  E.g., I
would presume with that option set to 0, something like the following
would be the case:
If a user does something like:
$ (umask 066 &&
> mkdir /var/tmp/mysecret &&
> umask 0 &&
> >/var/tmp/mysecret/cv60aXU8Gges82rY)
other users (other than superuser), although they would have access
to the file /var/tmp/mysecret/cv60aXU8Gges82rY, they wouldn't be able
to discover the name of the file (unless they caught it in some ps(1)
listing or discovered it via brute force or something like that), so
the file would be effectively protected to a fair degree by a certain
amount of security by obscrurity (this protection could be expanded
by increasing the complexity/randomness and length of the filename
and/or similarly layering it multiple levels deep under randomly
named directories).  It would seem, however, that if updatedb is run
by that user (or superuser) and scans /var/tmp/mysecret and the
mentioned option is set to 0, that other users would then be able to
use locate (or slocate or what have you) to determine the name of the
file /var/tmp/mysecret/cv60aXU8Gges82rY, and similarly for other
items (e.g. directories) beneath /var/tmp/mysecret where similar
protection means may also be used/attempted.  Having updatedb
effectively "leak" such security information would generally be
considered a bad thing, and that's probably why the default is for
that option to behave as if it is set to 1.

Now, ... as to the chown32() failing (EPERM), if updatedb is SGID to
slocate (or whatever group has GID 21), as would seem to be the case
on at least some of the man pages I check (e.g.:
http://www.google.com/search?hl=en&lr=&q=updatedb+%22--require-visibility%22+sgid&btnG=Search
), it seems a bit odd that the chown32() would fail - e.g. if it's
SGID to GID 21, and you own the file it's attempting the chown32()
on, and it's only trying to change the GID of the file to GID 21,
then that should generally succeed.  Perhaps something a bit more
interesting is going on?  What are the permissions on the updatedb
program, is it a binary executable, and what are the permissions of
all of the directories above the pathname upon which the chown32() is
failing, and what group or groups have GID 21?  Do any setgid(2) or
similar (setegid(2), seteuid(2), setfsuid(2), setregid(2),
setreuid(2), setuid(2), etc.) calls show up in the strace?  Oh, and
to make matters a bit more interesting, strace, invoked by
non-superuser generally can't trace suid/sgid stuff.  E.g. when I
attempt it, it appears the effect is that the suid/sgid on the binary
traced effectively don't take effect.  Is the updatedb file on a
filesystem that's mounted nosuid?  (and, "of course", I almost forgot
this little detail, as I started a simple sgid test under my HOME
directory ... but I've got /home mounted nosuid for security reasons;
except for / and /usr (and /opt where applicable, and possibly some
filesystems mounted beneath /usr and /opt), where the nosuid option
is applicable, I generally prefer to mount filesystems nosuid ... I
also like to generally have /usr (and some other filesystems) mounted
ro most of the time, for both security and performance reasons - note
also that having, e.g. /usr mounted ro on at least certain versions
of Red Hat (and possibly also Fedora?) can be a bit problematic due
to some nasty bugs in Red Hat - e.g. if /usr is mounted ro and one
installs a package with rpm, the package database is updated, no
errors are returned, but if any of the files were to be installed on
/usr ... they don't get installed!!!  Debian is much smarter and more
reasonable about things, and will at least return an error and not
install the package if one does something like that with dpkg, and
apt is smart enough that it can automagically remount /usr rw for
installations/updates, and remount it ro (if it can) when completed -
at least with suitable apt configuration).

references/excerpts:
http://lists.balug.org/pipermail/balug-talk-balug.org/2006-September/0
03817.html
http://lists.balug.org/pipermail/balug-talk-balug.org/2006-September/0
03817.html

Quoting David Alban:

> On 9/27/06, Michael Paoli wrote:
> > I haven't attempted a significant search, but I did stumble across
> > this:
> > "The updatedb command is not compatible, and custom scripts that use
> > updatedb may have to be updated"
> > which at least hints that things may be significantly different.
> > I found that in:
> > http://fedora.redhat.com/docs/release-notes/fc5/#id2948673
> > via:
> >
> http://www.google.com/search?hl=en&lr=&q=updatedb+%22fedora+core+5%22&btnG=Search
> > Perhaps comparing the source between the older and newer versions
> > would be useful ... but there may be lots of changes beyond just
> > that/those which are causing the particular difficulty you're
> > encountering.
>
> I, too, had found that.  And as a result, I'd compared the two man
> pages (slocate's updatedb in fc4 with mlocate's updatedb page in fc5)
> and found no difference in the -U and -o options I was using.
>
> However, going back and checking again, I noticed:
>
>        -l, --require-visibility IFLAG
>               Set  the  "require  file visibility before reporting it" flag
> in
>               the generated database to FLAG.
>
>               If FLAG is 0 or no, locate(1) outputs the database entries
> even
>               if  the user running locate(1) could not have read the
> directory
>               necessary to find out the file described by the database
> entry.
>
>               If  FLAG is 1 or yes (the default), locate(1) checks the
> permis-
>               sions of parent directories of each entry before reporting it
> to
>               the invoking user.  To make the file existence truly hidden
> from
>               other users, the database  group  is  set  to  slocate  and
> the
>               database  permissions  prohibit  reading  the  database by
> users
>               using other means than locate(1), which is sgid slocate.
>
> When I add "--require-visibility 0" it worked.  Thanks for prodding me
> to RRTFM (re-RTFM). :-)  Also, I needed to change -e DIRS to
> --add-prunepaths PATHS in my cron job.
>
> Excellent.  I get to use mlocate's updatedb on a machine on which I
> don't have root.