Bug 139950 - (IT#54302) slocate collects .automount files over nfs
slocate collects .automount files over nfs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: slocate (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Brock Organ
:
: 144921 (view as bug list)
Depends On:
Blocks: 156321 156323
  Show dependency treegraph
 
Reported: 2004-11-18 16:46 EST by Steve Conklin
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2005-346
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-17 11:50:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Conklin 2004-11-18 16:46:40 EST
User-Agent:       
Build Identifier: 

From IT#54302:

I've discovered an isue concerning updatedb.updatedb seems to collect
/.automount/blablabla files and records them in it's database.

The /etc/cron.daily/slocate.cron file contains:
#!/bin/sh
renice +19 -p $$ >/dev/null 2>&1
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net"

One would think that the "nfs" and "/net" types would be ignored as expected.
The database does indeed NOT include any found files BEGINNING with /net but the
database doe contain found files beginning with /.automount EVEN though these
are files found over nfs filesystems.

With potentially hundreds of mounts being established on a machine and that
creating the possibility of thousands if not hundreds of thousounds of files to
be recoreded into the updatedb database; this database coulld grow rather large.

The size of the database I'm not too worried about. I'm more worried about
hundreds if not thousands of machines (especially as we deploy more and more
RHEL nodes) all collecting the same data at the same time. This'll create a
network burst that potentially could disrupt nightly work related traffic. Also
network monitoring teams taking notice and deciding to shut off switches to
curve any network bursts that may occur. These network teams may insist that
there is a volunerabilty hack occurring. W don't want them thinking security
vulnerabilities of Red Hat linux do we ;-) ?

I'm more concerned though about the tool itself allowing these nfs mounted
filess to be collected even though the default configuration tells updatedb to
skip nfs filesystems.


Reproducible: Always
Steps to Reproduce:
1.Check the slocate database
2.
3.

Actual Results:  
it can contain .automount files

Expected Results:  
Shouldn't have nfs files in the database

Suggest changing slocate.cron to contain:
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net,/.automount"

This is similar to the problem described here:
http://www.redhat.com/archives/redhat-list/1999-July/msg00425.html
Comment 2 Steve Conklin 2004-11-22 15:19:43 EST
More from the Issue - simply adding /.automount won't solve the problem.

--------------

But we are still seeing this issue. With further investigation this is
how I believe we're seeing this issue.
We have:
/etc/auto-master CONTAINS
/opt/corp/lb        /etc/auto_loadbuild

Directories exists as:
/opt/corp -> /opt/soe
/opt/soe/lb
AS SUCH /opt/corp/lb exists and satisfies the auto map.

A request is made for /opt/corp/lb/blablabla and the mount is
established with an entry recorded in the /etc/mtab file as
/opt/corp/lb/blablabla

updatedb runs and correctly skips the /opt/corp/* stuff because of the
entry in slocate.cron :: the added /opt/corp to the dash 'e' (-e) list.
updatedb has not been told to skip /opt/soe stuff but was told to skip
nfs filesystems. updatedb traverses /opt/soe and ends up recording
everything (EVERYTHING even thrugh nfs) it finds there. However
/opt/soe/lb is a mounted filesystem; WELL actually /opt/corp/lb is the
mounted filesystem recorded in mtab but corp links to soe and soe
actually owns the lb directory which got mounted. So updatedb's syntax
to exlude nfs has been circumvented. This I think is a bug and in our
environment needlessly causes network storms (of light weight data
mind you:: just file names not file contents) traffic, performance
issues with each machine that runs updatedb and also huge slocate.db
files (as seen above 225Mg)

[snip]

Here is an update of this issues events this weekend after I removed
the link entry "/opt/corp" from slocate.cron and replaced it with the
directory enry /opt/soe

Again the link /opt/corp points at /opt/soe

[snip]

NOTCIE the size [of the database] is now only 2.8Mg as opposed to 225Mg.

[snip]

SOCATE.CRON FILE LOOKS LIKE:

[root@wcary468 cron.daily]# cat slocate.cron
#!/bin/sh
renice +19 -p $$ >/dev/null 2>&1
/usr/bin/updatedb -f "nfs,mvfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net,/.automount,/opt/soe"
[root@wcary468 cron.daily]#

So it seems having a 'link name' in a 'mount path' can circumvent the
checks for nfs mounted file systems that updatedb performs (whatever
the nature of that check is).
Comment 4 Miloslav Trmač 2005-01-30 16:50:07 EST
*** Bug 144921 has been marked as a duplicate of this bug. ***
Comment 10 Kevin Krafthefer 2005-04-13 11:10:11 EDT
problem is that a symbolic link can hide an NFS mount from updatedb.  For
example, if /a/b is an NFS mount point and /a/linktob is a symbolic link to
/a/b, updatedb will correctly NOT go down /a/b, but it will go down /a/linktob
because it does not detect it as an NFS mount, presumably because the /a/linktob
path is not in its list of NFS mounts.

Will this fix prevent slocate from traversing nfs mounts that are symlinked?
Comment 11 Miloslav Trmač 2005-04-13 18:47:25 EDT
AFAICS, the scenario in comment #10 should not be a problem simply because
updatedb never follows symbolic links to directories.

The scenario in comment #2 indeed looks possible, but that's only because amd
incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes
only paths with no symbolic links there.  Steve, please file a separate
bug against am-utils about this behavior; I'm sorry I have not noticed
this earlier. 
Comment 14 Miloslav Trmač 2005-04-16 05:49:33 EDT
(In reply to comment #11)
> The scenario in comment #2 indeed looks possible, but that's only because amd
> incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes
> only paths with no symbolic links there.  Steve, please file a separate
> bug against am-utils about this behavior; I'm sorry I have not noticed
> this earlier.
Sorry again... it seems autofs has (had?) a similar problem, so slocate should
handle symlinks in /etc/mtab correctly. It will be fixed together with the
other automounting issues.
Comment 18 Kevin Krafthefer 2005-05-12 14:42:26 EDT
We're seeing this happen when slocate accesses a symlink to an nfs mount point.
Comment 39 Red Hat Bugzilla 2005-09-28 10:38:03 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-345.html
Comment 40 Red Hat Bugzilla 2005-10-05 08:35:49 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-346.html

Note You need to log in before you can comment on or make changes to this bug.