Woo.. Trimmed the CC list on this one. Didn't catch the last
one. Sorry! :-)
Jose M. Alcaide wrote to Sean Lutner and [EMAIL PROTECTED]:
> 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 // [EMAIL PROTECTED] // [EMAIL PROTECTED] ******
> ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
Ryan Thompson <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
