Infrastructure Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

ACLs on Solaris 11

3121719Jan 29 2016 — edited Feb 5 2016

Can a user with ACL ownership to a file that is owned by a different user can change the permissions of the file?

I have a directory owned by user A and I have provided ACLs for user B (see below), but user B is not able to change the permissions of a newly created files under the directory? any ideas.

chmod -R A+user:<user B>:list_directory/read_data/add_file/write_data/add_subdirectory/append_data/read_xattr/write_xattr/execute/delete_child/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchronize:allow <file path>

This post has been answered by tmuehle on Feb 5 2016

Jump to Answer

Antonios Tsavdaris

Hi,

Not an expert here, have you set default ACL entries for the owner/group/others and ACL mask on the dir?

what does getfacl -d /your_filesystem show?

artsunixlabs

Please visit: Solaris ACL Model - Oracle Solaris ZFS Administration Guide

1_ oradba@solaris-slave:~$ chmod A+user:jdeveloper:read_data/execute:allow core

2_ oradba@solaris-slave:~$ ls -l core

-rw-------+ 1 oradba staff 164535027 Jan 28 23:21 core

3_ oradba@solaris-slave:~$ ls -dv core

-rw-------+ 1 oradba staff 164535027 Jan 28 23:21 core

0:user:jdeveloper:read_data/execute:allow

1:owner@:read_data/write_data/append_data/read_xattr/write_xattr

/read_attributes/write_attributes/read_acl/write_acl/write_owner

/synchronize:allow

2:group@:read_xattr/read_attributes/read_acl/synchronize:allow

3:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow

oradba@solaris-slave:~$

3121719

I've provided the ACLs but still not able to run chmod command on the files.

Ran the ls -lvd on a new test file created and the user admin has below ACLs for the test file.

0:user:admin:read_data/write_data/append_data/read_xattr/write_xattr

/execute/delete_child/read_attributes/write_attributes/read_acl

/write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow

Still when I run chmod on the testfile as admin user getting the below file.

ownership for test file

rw-r--r--+ 1 newadmin root 0 Feb 1 06:46 test

When I run chmod as admin user, who is not the owner of the file but provided ACLs,

chmod: WARNING: can't change test

Admin user is able to delete the file but cannot run chmod on that file

Cindys-Oracle

I started to scope this scenario on Friday but didn't get to finish. I think you will need to modify the file system's aclinherit and aclmode properties because they both restrict permissions by default. I'll try to do this later today.

Thanks, Cindy

3121719

Thank you, I've tried setting the aclmode to passthrough and still did not work. Let me know if you find something.

Cindys-Oracle

I was able to simulate this scenario and you definitely need to set aclmode to passthrough because this property determines subsequent chmod behavior. Its also important to remember that if you are working on directory contents, then you need to set the correct permissions on the directory container (level above). There might be an easier way but this is what I've found to work to allow changing file permissions.

The relevant section of the docs is here:

Setting ACL Inheritance on ZFS Files - Managing ZFS File Systems in Oracle® Solaris 11.3

See below.

Thanks, Cindy

# zfs get aclmode users

NAME PROPERTY VALUE SOURCE

users aclmode passthrough local

# su - userB

Oracle Corporation SunOS 5.11 11.3 January 2016

-bash-4.1$ cd /users/opendir

-bash-4.1$ cd subopendir

-bash-4.1$ ls -dv

drwxr-xr-x+ 2 root root 2 Feb 1 11:26 .

0:user:userB:list_directory/read_data/add_file/write_data/execute

:file_inherit/dir_inherit/inherited:allow

1:user:userA:list_directory/read_data/add_file/write_data/execute

:file_inherit/dir_inherit/inherited:allow

2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory

/append_data/read_xattr/write_xattr/execute/delete_child

/read_attributes/write_attributes/read_acl/write_acl/write_owner

/synchronize:allow

3:group@:list_directory/read_data/read_xattr/execute/read_attributes

/read_acl/synchronize:allow

4:everyone@:list_directory/read_data/read_xattr/execute/read_attributes

/read_acl/synchronize:allow

-bash-4.1$ touch file.b

-bash-4.1$ ls -lv file.b

-rwxr--r--+ 1 userB users 0 Feb 1 11:42 file.b

0:user:userB:read_data/write_data/execute:inherited:allow

1:user:userA:read_data/write_data/execute:inherited:allow

2:owner@:read_data/write_data/append_data/read_xattr/write_xattr

/read_attributes/write_attributes/read_acl/write_acl/write_owner

/synchronize:allow

3:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow

4:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize

:allow

-bash-4.1$ chmod A3=group@:read_data/write_data:allow file.b

-bash-4.1$ ls -lv file.b

-rwxrw-r--+ 1 userB users 0 Feb 1 11:42 file.b

0:user:userB:read_data/write_data/execute:inherited:allow

1:user:userA:read_data/write_data/execute:inherited:allow

2:owner@:read_data/write_data/append_data/read_xattr/write_xattr

/read_attributes/write_attributes/read_acl/write_acl/write_owner

/synchronize:allow

3:group@:read_data/write_data:allow

4:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize

:allow

3121719

Thank for your reply, couple of questions

1. From your test the file was originally owned by userB and in my case file was owned by userA and userB with acl ownership is trying to run chmod.

2. I was running command "chmod 777 test" on the test file instead like you tried "chmod A3=group@:read_data/write_data:allow file.b" does this make any difference?

artsunixlabs

Strange behavior of CHMOD: I agree...

We can allow jdeveloper to change the file but it works only once per session(my guess) - it fails the second time. - So jdeveloper is only allow to do it once.

The first time TRUSS exit returns condition = (0)
The second time TRUSS exit returns condition = (1)

#############################################

oradba@solaris-slave:~$ sudo chmod A+group:staff:write_xattr/write_attributes/write_acl/synchronize:allow file.b

oradba@solaris-slave:~$ ls -l file.b

-rwxr-x---+ 1 oradba staff 7875 Feb 2 03:16 file.b

Now as jdeveloper:::

oradba@solaris-slave:~$ su jdeveloper

Password:

#############################################

# First time JDEVELOPER changes the file it clearly works here...

#############################################

jdeveloper@solaris-slave:~$ chmod 0777 file.b

jdeveloper@solaris-slave:~$ ls -l file.b

-rwxrwxrwx 1 oradba staff 7875 Feb 2 03:16 file.b

TRUSS:

sysconfig(_CONFIG_PAGESIZE)		= 4096
umask(0)		= 022
umask(022)		= 0
lstat64("file.b", 0x08067018)		= 0
chmod("file.b", 0777)		= 0
pathconf("file.b", _PC_ACL_ENABLED)		= 2

_exit(0)

#############################################

# Second time JDEVELOPER is not allow to make further changes....

#############################################

jdeveloper@solaris-slave:~$ chmod 0755 file.b

chmod: WARNING: can't change file.b

jdeveloper@solaris-slave:~$

TRUSS:

sysconfig(_CONFIG_PAGESIZE)		= 4096
umask(0)		= 022
umask(022)		= 0
lstat64("file.b", 0x08067018)		= 0
chmod("file.b", 0777)		Err#1 EPERM [file_owner]

open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_OSCMD.mo", O_RDONLY) Err#2 ENOENT

fstat64(2, 0xF9BD70D0)		= 0
chmod: write(2, " c h m o d : ", 7)		= 7
WARNINGwrite(2, " W A R N I N G", 7)		= 7
: write(2, " : ", 2)		= 2

can't change write(2, " c a n ' t c h a n g e".., 13) = 13

file.bwrite(2, " f i l e . b", 6)

= 6

write(2, "\n", 1)

= 1

_exit(1)

tmuehle

Answer

Hi,

not sure if you are still having problems with this but if so please try the following:

# create a file in order to create a new zpool

ROOT > mkfile 1g /var/tmp/tpool

ROOT > zpool create tpool /var/tmp/tpool

# set zfs acl properties

ROOT > zfs set aclinherit=passthrough tpool

ROOT > zfs set aclmode=passthrough tpool

# owner could as well be left root (if so skipp chown ...)

ROOT> chown soladm /tpool/

ROOT > su - soladm

soladm:~$ cd /tpool/

# create a test file and set ACL

soladm:/tpool$ touch test.file

soladm:/tpool$ chmod A+user:u2034611:rwxpdDaARWcCos:fd----I:allow test.file

soladm:/tpool$ ls -l

total 1

-rw-r--r--+ 1 soladm staff 0 Feb 5 10:42 test.file

# switch to the user the ACLs were set for

soladm:/tpool$ su - u2034611

G u2034611 % cd /tpool

G u2034611 % ls -l

total 1

-rw-r--r--+ 1 soladm staff 0 Feb 5 10:42 test.file

G u2034611 % chmod 777 test.file

G u2034611 % ls -l

total 1

-rwxrwxrwx+ 1 soladm staff 0 Feb 5 10:42 test.file

G u2034611 % ls -V

total 1

-rwxrwxrwx+ 1 soladm staff 0 Feb 5 10:42 test.file

user:u2034611:rwxpdDaARWcCos:fd----I:allow

owner@:rwxp--aARWcCos:-------:allow

group@:rwxp--aARWc--s:-------:allow

everyone@:rwxp--aARWc--s:-------:allow

This should work as a from scratch example.

I remember ACL issues during the first months of Solaris 11 but I assume/hope you are at least running 11.2.

Cheers,

Thorsten

Marked as Answer by 3121719 · Sep 27 2020

tmuehle

Hi artsunixlabs,

could you check what the ACL look like before the first and before the second run?

I once ran into issues where the ACLs where lost after accessing it once.

Cheers,

Thorsten

3121719

Thanks, Issue was resolved and yes setting up aclinherit=passthrough was the fix.

1 - 11

Locked Post

New comments cannot be posted to this locked post.

Locked on Mar 4 2016

Added on Jan 29 2016

#oracle-solaris, #solaris-11

11 comments

2,152 views

Infrastructure Software

ACLs on Solaris 11

Comments

Post Details