Date: Tue, 31 Oct 2000 03:53:37 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: "Jose M. Alcaide" <jose@we.lc.ehu.es> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? Message-ID: <Pine.BSF.4.21.0010310353110.14845-100000@ren.sasknow.com> In-Reply-To: <39F6203D.123CCE95@we.lc.ehu.es>
next in thread | previous in thread | raw e-mail | index | archive | help
Jose M. Alcaide wrote to Warner Losh:
> Speaking of ls(1)...
>
> $ mkdir Arghh
> $ touch Arghh/{one,two,three}
> $ ls Arghh
> one three two
> $ chmod a-x Arghh
> $ ls Arghh && echo SUCCESS
> SUCCESS
> $ ls -l Arghh && echo SUCCESS
> SUCCESS
>
> ARGGGGHHHHH!!!! :-)
>
> This is not the expected behavior. If a directory does not have
> search permission, but it has read permission, a plain "ls" (or "ls -i")
> should list its contents, while "ls -l" should fail. And still worse,
> when ls fails to list the non-searchable directory contents, it
> does _not_ return an error code.
It's late... And I'm tired... But isn't that backwards?
"Search" (i.e., execute) permission on a directory implies that the
directory can be included as part of a directory search. In other words,
mapping to inodes is provided, but obtaining a list of files in the
directory is NOT. This is used by system administrators to "hide" a
directory of files, but still grant access to them if they are named
explicitly.
"Read" permission on a directory means that the directory can be listed.
Thus, if a directory has read permission, you can list the contents of it.
Permutations of directory permissions (ignoring write):
read and execute
(Normal) Can get a listing of files, and inodes for each file
So, files within the dir can be opened.
read, no execute
Can get a listing of filenames only. Can't actually map
filenames to inodes, so no open, ls -l, ls -li, etc.
execute, no read
Can't get a listing of filenames, but if you know the
filename in question, you can map it to an inode. So,
ls Arghh will never work (as it has to read the directory
to get the list of files!), but ls -l Arghh/one *will*
work, as it does not need to SEARCH to discover the name
of the file called "one".
no read, no execute
No service! :-)
FreeBSD's behaviour is as correct as the behaviour of any other UNIX
variant that I am aware of. The problem is not with ls.
See my response to your next post (I'll have to type it, first ;-)
Hope this helps,
- Ryan
--
Ryan Thompson <ryan@sasknow.com>
Network Administrator, Accounts
Phone: +1 (306) 664-1161
SaskNow Technologies http://www.sasknow.com
#106-380 3120 8th St E Saskatoon, SK S7H 0W2
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010310353110.14845-100000>