If I define: drw-rw---- 2 tmarques tmarques 4096 Jul 3 18:32 teste then the "what" file inside can be listed, resulting in this: ls -l teste/ ls: cannot access teste/what: Permission denied total 0 -????????? ? ? ? ? ? what Reproducible: Always Steps to Reproduce: 1.create a directory 660 permission 2.create any file inside him 3.ls the directory Actual Results: the file is listed with ???? in the place of file properties, it's name is listed and all other files that exist in the directory are too. ls -l teste/ ls: cannot access teste/what: Permission denied total 0 -????????? ? ? ? ? ? what Expected Results: it shouldn't be able to list anything in that directory I don't know if this has any huge security implications. Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.24-gentoo-r8 x86_64) ================================================================= System uname: 2.6.24-gentoo-r8 x86_64 Intel(R) Xeon(R) CPU E5430 @ 2.66GHz Timestamp of tree: Fri, 27 Jun 2008 15:35:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 2.1.5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61 sys-devel/automake: 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -march=nocona -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://darkstar.ist.utl.pt/gentoo/" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
anything `ls` can do, other things can do
Can you test with gentoo-sources-2.6.26-r1.
All kernel versions will do the same thing, as this is intended behaviour. On a directory read permission without execute allows you to see what it contains, but not access it. You probably want the other way around, execute without read. That allows you to access the directory's contents if you know the exact path, but not to list it. See here for more info: http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/10862-linux-file-permissions.html
Shouldn't it then allow to see the permissions and filesystem information on the file, even though it can be accessed? After all, seeing the contents of the file implies that, doesn't it?
Reopening bug report till it is completely dismessed, I still believe this is a bug.
Except you can't see the contents of the file. If you run 'cat' or similar on it, you will get permission denied. Was this an oversight or do you have other reasons to believe this behaviour is a bug? The only thing you can do is know that the file with that name exists in the directory. This is because when the directory is opened, its contents can be read, through code along the lines of: fd = open('teste', O_RDONLY | O_DIRECTORY); data = read(fd, buf, bufsize); close(fd); And the above code is valid because you have read access to the directory (see 2nd line of your original message).
First and foremost the way "ls" is handling is not what I would call elegant: ls -l teste/ ls: cannot access teste/what: Permission denied total 0 -????????? ? ? ? ? ? what It CAN list the file, it knows it's there, but it gives a permission denied, "ls" itself, when accessing the file. Cat to the file gives the same error, which is expectable: "Execute permission (also called the "search bit") allow you to use the directory name when accessing files inside that directory (to cd into the direcroty)." Ok, now it shouldn't be giving the permission denied error, IMHO, and should just show the ?????????? and the corresponding file(s). I know now that it can list the directory, it's not an error, but the way it is handling the permissions of the directory it's not optimal: ------------------------------------------------------------------------ ls: impossível aceder a teste/asdasd: Permission denied ls: impossível aceder a teste/asdasdddd: Permission denied ls: impossível aceder a teste/asdasddddaadd: Permission denied ls: impossível aceder a teste/asdasddddaaddggcc: Permission denied ls: impossível aceder a teste/asdasddddaa: Permission denied ls: impossível aceder a teste/asdasddddaaddgg: Permission denied total 0 -????????? ? ? ? ? ? asdasd -????????? ? ? ? ? ? asdasdddd -????????? ? ? ? ? ? asdasddddaa -????????? ? ? ? ? ? asdasddddaadd -????????? ? ? ? ? ? asdasddddaaddgg -????????? ? ? ? ? ? asdasddddaaddggcc ------------------------------------------------------------------------ I personally don't see why we "ls" should list anything in this case, since it can't open it anyway - I know it's allowed due also to the filesystem's structure but it doesn't make any sense to me. If this is really the intended behavior, I ask that it lists something like this instead: ------------------------------------------------------------------------ ls: can't access file's permissions/ownership(can't cross directory): Permission denied total 0 -????????? ? ? ? ? ? asdasd -????????? ? ? ? ? ? asdasdddd -????????? ? ? ? ? ? asdasddddaa -????????? ? ? ? ? ? asdasddddaadd -????????? ? ? ? ? ? asdasddddaaddgg -????????? ? ? ? ? ? asdasddddaaddggcc ------------------------------------------------------------------------ Something like this, with a proper explanation of why this happens and just an error for a directory with more than one file, since it's going to happen to every file in there. Tiago Marques
Sorry, should have reread it before posting. Last paragraph should have read: Something like this, with a proper explanation of why this happens and just *ONE* error for a directory with more than one file... (In reply to comment #7) > First and foremost the way "ls" is handling is not what I would call elegant: > > ls -l teste/ > ls: cannot access teste/what: Permission denied > total 0 > -????????? ? ? ? ? ? what > > It CAN list the file, it knows it's there, but it gives a permission denied, > "ls" itself, when accessing the file. Cat to the file gives the same error, > which is expectable: > > "Execute permission (also called the "search bit") allow you to use the > directory name when accessing files inside that directory (to cd into the > direcroty)." > > Ok, now it shouldn't be giving the permission denied error, IMHO, and should > just show the ?????????? and the corresponding file(s). > > I know now that it can list the directory, it's not an error, but the way it is > handling the permissions of the directory it's not optimal: > > ------------------------------------------------------------------------ > ls: impossível aceder a teste/asdasd: Permission denied > ls: impossível aceder a teste/asdasdddd: Permission denied > ls: impossível aceder a teste/asdasddddaadd: Permission denied > ls: impossível aceder a teste/asdasddddaaddggcc: Permission denied > ls: impossível aceder a teste/asdasddddaa: Permission denied > ls: impossível aceder a teste/asdasddddaaddgg: Permission denied > total 0 > -????????? ? ? ? ? ? asdasd > -????????? ? ? ? ? ? asdasdddd > -????????? ? ? ? ? ? asdasddddaa > -????????? ? ? ? ? ? asdasddddaadd > -????????? ? ? ? ? ? asdasddddaaddgg > -????????? ? ? ? ? ? asdasddddaaddggcc > ------------------------------------------------------------------------ > > I personally don't see why we "ls" should list anything in this case, since it > can't open it anyway - I know it's allowed due also to the filesystem's > structure but it doesn't make any sense to me. > > If this is really the intended behavior, I ask that it lists something like > this instead: > > ------------------------------------------------------------------------ > ls: can't access file's permissions/ownership(can't cross directory): > Permission denied > total 0 > -????????? ? ? ? ? ? asdasd > -????????? ? ? ? ? ? asdasdddd > -????????? ? ? ? ? ? asdasddddaa > -????????? ? ? ? ? ? asdasddddaadd > -????????? ? ? ? ? ? asdasddddaaddgg > -????????? ? ? ? ? ? asdasddddaaddggcc > ------------------------------------------------------------------------ > > Something like this, with a proper explanation of why this happens and just an > error for a directory with more than one file, since it's going to happen to > every file in there. > > Tiago Marques >
OK, so your issue is not with the behaviour of the system, but with the way that the information is presented by 'ls'?
(In reply to comment #9) > OK, so your issue is not with the behaviour of the system, but with the way > that the information is presented by 'ls'? > Actually, it's with both but, as for the behavior, I don't contend it, IF this is done for some reason - I didn't say I agree with it: > I personally don't see why we "ls" should list anything in this case, since it > can't open it anyway... It's useless to be able to list the names of files in a DIR if we can't see it's ownership and permissions. As for the way the information is displayed, that's also an issue and I provided what I think is a better example. Best regards, Tiago Marques
OK. Behaviour-wise, this is not the place to challenge decades-old unix semantics. But maybe the base-system team will point you in the right direction to get 'ls' output improved.
the output of ls looks perfectly reasonable to me. i dont understand why you have a problem with the output especially considering you're purposefully breaking things in ways that dont make any sense at all. in other words, i'm not going to change the output of ls, nor am i going to ask for it (since i dont agree with you that it's wrong in any way). if you wish to pursue this further, you can ask the upstream maintainers themselves: http://www.gnu.org/software/coreutils/
