From owner-freebsd-hackers Tue Oct 31 1:50:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 149B537B4D7 for ; Tue, 31 Oct 2000 01:50:28 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id DAA32024; Tue, 31 Oct 2000 03:53:38 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Tue, 31 Oct 2000 03:53:37 -0600 (CST) From: Ryan Thompson To: "Jose M. Alcaide" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? In-Reply-To: <39F6203D.123CCE95@we.lc.ehu.es> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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