Date: Tue, 31 Oct 2000 03:49:43 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: "Jose M. Alcaide" <jose@we.lc.ehu.es> Cc: hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? Message-ID: <Pine.BSF.4.21.0010310336140.14845-100000@ren.sasknow.com> In-Reply-To: <39F6AC8D.542149FC@we.lc.ehu.es>
next in thread | previous in thread | raw e-mail | index | archive | help
Woo.. Trimmed the CC list on this one. Didn't catch the last
one. Sorry! :-)
Jose M. Alcaide wrote to Sean Lutner and hackers@FreeBSD.ORG:
> Sean Lutner wrote:
> >
> > I may just be being naive here, which is why I took this off the list. I
> > don't understand how a directory that is a-x will not let you run ls -l on
> > it.
It won't, because in order to generate a listing of filenames in the
directory, you must have read access to that directory. To run ls -l,
both read AND search are required, as you must be able to a) get a list of
files, b) map those files to inodes (to return size, link and date
information, etc)
> > As you can see, after changing the permissions, you cannot run ls -l as
> > you could before. Perhaps I don't have the broken version, or there is
> > something I am missing. At any rate, a better understanding would be nice.
> >
What broken version? :-)
> If a directory does not have search permission, the i-node contents of
> each of its entries cannot be examined. Under these circumstances,
> the directory listing "per se" does not fail, but the information
> requested cannot be shown. For example, in Solaris (and in SunOS 4.x):
>
> $ ls -ld Test/
> drw-r----- 2 jose lsi 512 oct 25 11:13 Test/
> $ ls Test
> 1 2 3
> $ ls -i Test
> 288799 1 288800 2 288801 3
> $ ls -l Test
> Test/1: Permission denied
> Test/2: Permission denied
> Test/3: Permission denied
> total 0
> $
>
> Anyway, I found something interesting: the bash shell is involved
> in some way:
>
> Using bash:
When you use wildcard expansion, the shell is definitely involved.
Remember it is the shell, not ls, that expands wildcards.
>
> $ mkdir Test
> $ touch Test/{1,2,3}
> $ chmod a-x Test
> $ ls Test && echo SUCCESS
> SUCCESS <------ WRONG!!
> $ /bin/ls Test && echo SUCCESS
> 1 2 3 <------ This works as expected (?!?!??)
What sort of shell functions/aliases do you have defined in bash? Looks
like ls is possibly aliased to something. (Possibly with different
command line arguments to /bin/ls).
> Using [t]csh:
>
> $ csh
> %ls -ld Test
> drw------- 2 jose lsi 512 25 oct 10:49 Test
> %ls Test
> 1 2 3 <------ This works as expected
> %ls -i Test <------ WRONG!!
> %which ls
> /bin/ls
> %
>
Why not call /bin/ls explicitly in your examples, to remove the inherent
ambiguity?
> Using both bash and csh, 'ls -i' and 'ls -l' give nothing and
> don't return any error when the directory does not have search permission.
> "ls -i" should work, since getdirentries(2) only requires that
> the directory must be opened for reading. The behavior of "ls -l" may
> be a subject for discussion.
"Opened for reading" is different than "has execute (search) permission".
The two can be independent. Even still, I don't see where
getdirentries(2) "only requires the directory must be open for reading".
If that IS the case, then the -doc people have a change to commit :-)
Search permission is required to map pathnames to inodes. That's a
requirement of the kernel (and, consequently, of kernel calls) for normal
users.
> Cheers,
> -- JMA
> ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ******
> ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
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.0010310336140.14845-100000>