FS#6170 - XFS ACL Broken

Attached to Project: Arch Linux
Opened by Christ Schlacta (aarcane) - Saturday, 06 January 2007, 10:17 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 06 May 2007, 20:35 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Judd Vinet (judd)
Architecture not specified
Severity High
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

ACL in XFS is Broken at the current time. ACL modification simply changes the ACL, and updates the chmod file permissions, but only the chmod file permissions are honored. to complicate this matter, the chmod group file permissions ar enot properly updated.

[aarcane@kropstnega xfs]$ ls -la
total 12
drwxr-xr-x 2 aarcane users 19 2007-01-04 03:45 .
drwxr-xr-x 7 root root 4096 2007-01-04 02:19 ..
-rw-rwxr-- 1 aarcane users 8 2007-01-04 03:48 myfile
[aarcane@kropstnega xfs]$ getfacl myfile
# file: myfile
# owner: aarcane
# group: users
user::rw-
user:test:--x
group::r--
mask::rwx
other::r--

[aarcane@kropstnega xfs]$ groups test
media
[aarcane@kropstnega xfs]$ sudo su test -c ./myfile
bash: ./myfile: Permission denied
[aarcane@kropstnega xfs]$ sudo su test -c "cat ./myfile"
cat: ./myfile: Permission denied
[aarcane@kropstnega xfs]$ groups
disk wheel video audio optical users media
[aarcane@kropstnega xfs]$ ./myfile
-bash: ./myfile: Permission denied
[aarcane@kropstnega xfs]$



as you can see in the above example, the user test should have execute permissions, but doesn't. Furthermore, despite the group users being listed as having execute permission, no user in the users group can execute it. Lastly, when ACLs are in use, there should be a + at the end of the ls filepermissions output to indicate that not all permissions could be shown, but it isn't there.
This task depends upon

This task blocks these from closing
 FS#6767 - Post 0.8 Installation ISO bugs and feature requests 
Closed by  Tobias Powalowski (tpowa)
Sunday, 06 May 2007, 20:35 GMT
Reason for closing:  Fixed
Comment by Mike (PinkFreud) - Sunday, 01 April 2007, 03:12 GMT
Using the execute bit without the read bit only works for compiled executables. For scripts, the shell *must* be able to read the file. As the shell runs as the current user, that user needs to have read access to the file, as well as having the execute bit.

For example, consider the following shell script (example below is given on an ext3 filesystem):

#!/bin/sh

echo "Hello, world!"

foo@eriador:~/tmp$ id
uid=1001(foo) gid=1004(foo) groups=1004(foo)
foo@eriador:~/tmp$ ls -al helloworld.sh
-rwxr-x--x 1 sauron sauron 32 Mar 31 22:57 helloworld.sh
foo@eriador:~/tmp$ ./helloworld.sh
/bin/sh: ./helloworld.sh: Permission denied
foo@eriador:~/tmp$

Note that foo's shell was unable to read the script, and therefore could not execute it. This behavior is by design, and is not a bug.

Submitter should try this test with a compiled executable.
Comment by Tobias Powalowski (tpowa) - Sunday, 06 May 2007, 20:12 GMT
is this now fixed?
Comment by Eduard Warkentin (bekks) - Sunday, 06 May 2007, 20:27 GMT
i just tried it out:

ls -lha /
-r-xrwxr-- 1 camel users 509K 6. Mai 22:16 bash

getfacl /bash
# file: bash
# owner: camel
# group: users
user::r-x
group::rwx
other::r--

midgaard100 / # su - camel2
[camel2@midgaard100 ~]$ groups
users camel2
[camel2@midgaard100 ~]$ /bash
[camel2@midgaard100 ~]$ exit
exit
[camel2@midgaard100 ~]$ exit
logout

as far as _i_ can see, there is no bug to me

Loading...