Good question. One good answer is: allow it to respect the bits on restricted directories.
Notice that directories require the execute bit. Here's why: "execute" on a directory means searchable. With "read", you can list a directory. But you can't access files in it without "execute". A directory which is readable but not searchable is not all that exciting, however ... A directory which is searchable but not readable allows you to get to known files while keeping the whole list hidden from prying eyes. You still would need access rights to the file in question. For example, I keep my home directory unreadable, but I must render it searchable because of certain things it holds, like my personal web sub-dir. (To support the tilde hack in web space.) The web content is completely transparent (listable, readable, searchable, copyable) but the parent home directory is opaque. You can get even more fine-grained control by using ACLs. So if I don't want people to be able to read my home dir, then I don't want them to bypass the filesystem and get the info from mlocate.db. Yeah ... the mere existence of a file may constitute a security risk. Call it meta-data. Call it leakage. On Mon, Sep 30, 2013 at 11:00 AM, John McKown <[email protected]> wrote: > I am looking a "porting" the Linux updatedb/locate program in the mlocate > rpm to run on another UNIX system (z/OS to be exact). I don't understand > why the mlocate.db is not world readable. Instead, the locate program is > marked setgid. The only reason I have come up with is that the updatedb > program loads the names of all the local (and perhaps NFS) file names into > the mlocated.db file. And some of those may be in directories which are > unreadable by some users. > > I am not really going to port the actual code, because I am pretty sure > that I'm going to put the data into a sqlite3 data base so that others can > write code to "do things" with it. > > This is where I don't understand. How can simply knowing if a file exists > or not be a security concern? I admit to being ignorant of this because a > user in z/OS can generally get a listing of the names of all the data sets > (files) which exist on a z/OS system even if they cannot read them. Yeah, > I've got some of those and one consultant was "uppity" about "why can't I > read that? Justify it to me!!!" Who which I replied (quoting W.C. Fields): > "Go away, boy, you bother me!" > > -- > I have _not_ lost my mind! It is backed up on a flash drive somewhere. > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- -- R; Rick Troth Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
