This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 469864 - File attributes and permissions missing / not recognized.
File attributes and permissions missing / not recognized.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-04 09:52 EST by Kent Olsen
Modified: 2013-01-09 23:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-04 15:48:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kent Olsen 2008-11-04 09:52:30 EST
File attributes are being displayed as '?' for files in a directory not owned by the task running the *ls* command.  (root is not affected.)  Access to the files is denied even though implicit access should be granted due to all of the files/directories in the path having at least global read permissions.

Instructions to Reproduce:

Given user1 and user2 with home directories at /home/user1 and /home/user2.

- Set the attributes for /home/user1 to 744
- Ensure that some files/directories have read-other permission
- Login as user2
- ls -l /home/user2

All files/directories are displayed as:

-????????? ? ? ? ?                ? a.out


The O/S is updated through the mods available on Nov 4, 2008 at 9:30AM EST.

A real example follows:

File list of /home/kent:

[kent@krh ~]$ ll
total 340
-rwxrwxr-x 1 kent kent  10077 2008-11-04 09:01 a.out
-rw-r--r-- 1 kent kent 242585 2008-11-04 08:32 a.sql
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Desktop
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Documents
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Download
drwxr-xr-x 4 kent kent   4096 2008-10-29 17:36 Larn
-rw-rw-r-- 1 kent kent   4826 2008-11-04 09:16 letter
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Music
-rw-rw-r-- 1 kent kent   3182 2008-11-04 09:01 parse_letter.c
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Pictures
-rw-rw-r-- 1 kent kent    802 2008-11-04 09:19 proc.sql
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Public
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Templates
drwxr-xr-x 2 kent kent   4096 2008-10-10 21:40 Videos
-rwxrwxrwx 1 kent kent  32487 2008-11-04 09:22 x
-------rwx 1 kent kent      0 2008-11-04 09:47 y

File list of /home/kent displayed from the db2inst1 user:

[db2inst1@krh ~]$ ls -l /home/kent
ls: cannot access /home/kent/Public: Permission denied
ls: cannot access /home/kent/a.out: Permission denied
ls: cannot access /home/kent/Desktop: Permission denied
ls: cannot access /home/kent/y: Permission denied
ls: cannot access /home/kent/Videos: Permission denied
ls: cannot access /home/kent/Download: Permission denied
ls: cannot access /home/kent/proc.sql: Permission denied
ls: cannot access /home/kent/Pictures: Permission denied
ls: cannot access /home/kent/letter: Permission denied
ls: cannot access /home/kent/Music: Permission denied
ls: cannot access /home/kent/Templates: Permission denied
ls: cannot access /home/kent/a.sql: Permission denied
ls: cannot access /home/kent/Documents: Permission denied
ls: cannot access /home/kent/parse_letter.c: Permission denied
ls: cannot access /home/kent/Larn: Permission denied
ls: cannot access /home/kent/x: Permission denied
total 0
-????????? ? ? ? ?                ? a.out
-????????? ? ? ? ?                ? a.sql
d????????? ? ? ? ?                ? Desktop
d????????? ? ? ? ?                ? Documents
d????????? ? ? ? ?                ? Download
d????????? ? ? ? ?                ? Larn
-????????? ? ? ? ?                ? letter
d????????? ? ? ? ?                ? Music
-????????? ? ? ? ?                ? parse_letter.c
d????????? ? ? ? ?                ? Pictures
-????????? ? ? ? ?                ? proc.sql
d????????? ? ? ? ?                ? Public
d????????? ? ? ? ?                ? Templates
d????????? ? ? ? ?                ? Videos
-????????? ? ? ? ?                ? x
-????????? ? ? ? ?                ? y
Comment 1 Jesse Keating 2008-11-04 10:02:43 EST
Is this a selinux or file system ACL issue?  Have you checked for selinux denials or looked at getfacl to see the ACLs?
Comment 2 Kent Olsen 2008-11-04 10:24:59 EST
The issue is "one way" in that the db2inst1 directory looks fine from user kent, but not vice-versa.


getfacl looks normal:

# file: home/kent
# owner: kent
# group: kent
user::rwx
group::r--
other::r--

selinux is disabled:

cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
#SELINUX=enforcing
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted
Comment 3 Jesse Keating 2008-11-04 10:53:58 EST
You didn't show the acl output from the user who can't see.

Also, the selinux config file setting doesn't mean that it wasn't booted with selinux enabled.  Editing a config file doesn't magically turn it off.
Comment 4 Kent Olsen 2008-11-05 10:02:23 EST
Hi Jesse,

That was the getfacl from the use that can't see.

After several hours of chasing this, an offhand comment from a pretty good linux admin steered me to the resolution.  "You need execute permission on a directory to be able to *cd* to it."

By setting execute-other on the directory, everything shows up fine and behaves as I would expect.

This does not appear to be specific to rawhide.  I was able to find hundreds of posts on the web where a similar situation occured.  I read the posts on several dozen forums and nowhere was the underlying issue posted in a response, nor was a workable solution given.  (One post even suggested a reinstall of the O/S.)  Ubuntu, Debian, Rh, etc. all seem to exhibit this same behavior.  My guess is that it came in with a particular kernel change.

It makes no sense to be able to "see" files in another directory but not actually access them.  This is especially true in this case since read-other permission is explicitly set on all directories in the target path.

I've not been able to find an RFC that describes, mandates, or supports the current behavior.  This seems like kernel or base O/S bug.


Kent
Comment 5 Jesse Keating 2008-11-05 11:05:31 EST
Hrm, throwing it at kernel for lack of a better target.
Comment 6 Eric Sandeen 2008-11-11 13:37:38 EST
Weird.  Will try to find enough time to figure out who else to pass this off to ;)
Comment 7 Bug Zapper 2008-11-25 23:44:30 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Eric Sandeen 2008-12-04 15:48:08 EST
Ok, so, let's see.  I have user1 and user2, dirs set up as you suggest, with file "file" in each, and then user1 tries to ls -l user2

Setup, shown from root's prompt:

# ls -ld user2
drwxr--r-- 2 user2 root 4096 2008-12-04 14:20 user2
# ls user2
file
# ls -l user2/file
-rw-r--r-- 1 user2 root 0 2008-12-04 14:20 user2/file

Now as user1:

$ ls -l user2/
ls: cannot access user2/file: Permission denied
total 0
-????????? ? ? ? ?                ? file

This is what's happening under the covers on the ls -l (abbreviated....)

open("user2/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3

We can open the dir for reading as an "other" user, as specified by the perms.

fstat(3, {st_dev=makedev(8, 11), st_ino=1063, st_mode=S_IFDIR|0744, st_nlink=2, st_uid=502, st_gid=0, st_blksize=4096, st_blocks=8, st_size=4096, st_atime=2008/12/04-14:24:46, st_mtime=2008/12/04-14:20:33, st_ctime=2008/12/04-14:23:11}) = 0

fstat of the dir itself works fine...

fcntl(3, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
getdents(3, {{d_ino=1063, d_off=207231174, d_reclen=24, d_name="."} {d_ino=234337, d_off=1630955762, d_reclen=24, d_name="file"} {d_ino=9839, d_off=2147483647, d_reclen=24, d_name=".."}}, 4096) = 72

We can also do getdents on the directory, so we know the contents of the dir.  This makes sense (the dir is readable, and we are simply reading that directory inode).

lstat("user2/file", 0xdb78b0)           = -1 EACCES (Permission denied)

but when we try to lstat the file within the directory, that fails.  

> It makes no sense to be able to "see" files in another directory but not
> actually access them. 

I don't *think* that any of this is unexpected; you can access the directory listing itself (o+r on that dir) but you cannot access the files they reference (the dir is not executable so you cannot actually access files it contains (the inodes it refers to)).

I'm going to NOTABUG this unless you can convince me otherwise ;)

ls -l output could sure be nicer, though.

Note You need to log in before you can comment on or make changes to this bug.