# CIFS handling of directory execute permissions

## tld

I'm running the gentoo-sources 2.6.32-gentoo-r7 kernel.  Forgive me if this possibly belongs in off the wall, as I think the behavior I'm running into here is not specific to gentoo.

I've discovered something pretty odd regarding the way that the CIFS file system handles directory execute permissions (or in the case of windows servers I believe it's LIST_DIRECTORY privileges), and was wondering if anyone knows of a work-around, or even if anyone has any insight as to the logic behind this behavior.

If the client user does not have execute/list_directory privileges to a directory on a mounted share, attempting to read/open the directory does NOT report permission denied, but instead silently reports it as an empty directory.  I have an application where ideally I'd like to know the difference.  I've noticed that this is not the case when the same shares are mounted under Windows with NET USE, which does in fact report permission denied when attempting to access such directories.

I installed sharkwire to get a look at exactly what's going on with the linux CIFS client side when attempting to do an "ls -l /unreadable/directory/path".  It sends a FIND_NEXT2 request to the server and the server expressly responds with STATUS_ACCESS_DENIED.  After that the client attempts to send yet another FIND_NEXT2 request and the server sends a STATUS_INVALID_HANDLE response.

Pretty odd to say the least.  Does anyone know if this is intentional behavior?  I can't find any mount options that appear to affect this (and I doubt there are) but if anyone knows of any please let me know.

Thanks

Tom

----------

## BradN

From what you've said, it certainly sounds like a bug in CIFS.  I would report it to their bug tracker or mailing list or whatever they use.

----------

## tld

Yea, that what I just did.  I sent an email to the address linked here:

http://us1.samba.org/samba/Linux_CIFS_client.html

I hope this isn't intended behavior, but it appears it's been that way for a very long time, even in the SMB file system.

Tom

----------

## tld

For anyone interested, at the suggestion of Steve French with the samba project I logged a bug about this behavior:

https://bugzilla.samba.org/show_bug.cgi?id=7535

Tom

----------

