Restrict user access

Hi there

I have an application user on my system that wants accesses to these file systems as such:

rwx:

/SAPO
/SAPS12
/R3_888
/R3_888B
/R3_888F
/R3_888R

r:
/usr/sap

these are the existing FS permissions:ownerships:

[root@H99A100 ~]# ls -ld /SAPO
drwxrwxr-x 64 ZODCIFUSR ODCgrp 12288 Nov 25 11:02 /SAPO

[root@H99A100 ~]# ls -ld /SAPS12
drwxrwxr-x 5 s12adm ODCgrp 4096 Nov  7 13:49 /SAPS12

[root@H99A100 ~]# ls -ld /R3_888
drwxrwxr-x 129 s12adm ODCgrp 4096 Nov 10 09:56 /R3_888

[root@H99A100 ~]# ls -ld /R3_888B
drwxrwxr-x 31 s12adm ODCgrp 4096 Nov  7 15:03 /R3_888B

[root@H99A100 ~]# ls -ld /R3_888F
drwxrwxr-x 43 s12adm ODCgrp 4096 Nov 21 17:16 /R3_888F

[root@H99A100 ~]# ls -ld /R3_888R
drwxrwxr-x 4 s12adm ODCgrp 4096 Nov  7 15:03 /R3_888R

[root@H99A100 ~]# ls -ld /usr/sap
drwxrwxr-x 5 s12adm sapsys 4096 Oct 25 22:16 /usr/sap

the user:

[root@H99A100 ~]# id ZODCIFUSR
uid=2020(ZODCIFUSR) gid=200(ODCgrp) groups=200(ODCgrp),0(root) context=root:system_r:unconfined_t:SystemLow-SystemHigh

so how do i go by providing user ZODCIFUSR access to the file systems stated above without setting ACLs on the system? (or is ACLs the only way to do it?)

right now, he's in group 0, so he can pretty much access all the FS but this is just a temp workaround

I was thinking of adding the user to supplementary groups on which the FS are grouped (i.e. sapsys, ODCgrp)

please help, if ACLs is the way to do it, please let me know because i am not very good with the commands

thank you

From the looks of the list, it seems everybody has access (read access at least) to those files, not just "ZODCIFUSR".

Anyway, you can remove that user from GID 0 and it should still work fine since most of the folders also belong to GID 200.

The only "problem" I see is with /usr/sap. Either you take away permissions from the whole group and make ZODCIFUSR a member of secondary group "sapsys", or you use ACLs.

Hi Verde

I thought of the same thing, there's no reason giving fancy restriction to the user unless he's removed from group 0, and ACL does have mysterious ways working with permissions and maskings

If I were to use ACLs, say to allow user ZODCIFUSR to have read only access for directory and files under /usr/sap, how would the command be? Is this correct?

setfacl -m d u:ZODCIFUSR /usr/sap

Also I did a bit of Googling and it says that the permissions and ownerships are inherited; even after using mv or cp -p command. Is this true?

Before you can assign an ACL, you have to make sure that the filesystem supports them:

tune2fs -l /dev/sdX/ | grep options

If you run mount you may also get the details. There should be an "acl" option somewhere in the mount options.

If it does not support ACLs, you can always remount the filesystem:

mount -o remount,acl /usr/sap

Having said so, your ACL command is almost correct:

setfacl -m d:u:ZODCIFUSR:r /usr/sap

When an ACLs (POSIX ACL) is set on a directory, all new files created inside inherit the default ACL. If for some reason you want to copy a file that has an ACL to a directory that does not use ACLs, both cp -p and mv will preserve the original ACL.

Thank you verdepollo, I checked my disks and the partition, none of them even show any output when i run the tune2fs -l command (output shows the result for one of the disk)

[root@H99A100 dev]# ls -lrt sd*
brw-r----- 1 root disk 8,  2 Nov 22 22:30 sda2
brw-r----- 1 root disk 8,  0 Nov 22 22:30 sda
brw-r----- 1 root disk 8,  1 Nov 22 22:31 sda1
brw-r----- 1 root disk 8,  3 Nov 25 15:14 sda3
brw-r----- 1 root disk 8, 16 Nov 28 13:46 sdb
brw-r----- 1 root disk 8, 32 Nov 28 13:46 sdc
[root@H99A100 dev]#

[root@H99A100 dev]# tune2fs -l /dev/sdb
tune2fs 1.39 (29-May-2006)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb
Couldn't find valid filesystem superblock.

none of the existing FS on the system is ACL supported, as per mount command

/dev/mapper/vgSAP-lv_s12_03 on /usr/sap/trans type ext3 (rw)

I doubt the client will agree with remounting the FS with acl mount option, but would it possible to create ACL anyways, without the FS mount options being ADL enabled? What would be the consequences to this?

Thanks again for the full command, I've always been wary of ACLs :o

---------- Post updated at 06:45 PM ---------- Previous update was at 06:27 PM ----------

So I tested this on my test server, but the weird thing is when I did mount, all the other FS but /tmp is acl enabled, even after manually enabling acl for /tmp

my-xftp0:~ # tune2fs -l /dev/sda8
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          1d4351d3-dbf5-42b8-9b78-a29b7dcf5e9c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              655360
Block count:              2620603
Reserved block count:     131030
Free blocks:              2537308
Free inodes:              655216
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      639
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Thu Nov 17 11:44:04 2011
Last mount time:          Wed Dec  7 15:30:06 2011
Last write time:          Wed Dec  7 15:30:06 2011
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Nov 17 11:44:04 2011
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      b38a25f8-9d33-45c8-81ef-b51c55d4fba2
Journal backup:           inode blocks

check out the FS in blue, they were acl enabled all along

my-xftp0:~ # mount
/dev/sda1 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
devtmpfs on /dev type devtmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda2 on /boot/efi type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true)
/dev/sda4 on /home type ext3 (rw,acl,user_xattr)
/dev/sda7 on /opt type ext3 (rw,acl,user_xattr)
/dev/sda8 on /tmp type ext3 (rw)
/dev/sda5 on /usr type ext3 (rw,acl,user_xattr)
/dev/sda6 on /var type ext3 (rw,acl,user_xattr)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)

attempting to set /tmp acl enabled failed:

my-xftp0:~ # mount -o remount, acl /tmp
my-xftp0:~ # tune2fs -l /dev/sda8 | grep -i acl
my-xftp0:~ #

nonetheless, attempting to set user test with read permissions for /tmp worked

my-xftp0:~ # setfacl -m d:u:test:r /tmp
my-xftp0:~ # 
my-xftp0:~ # getfacl /tmp
getfacl: Removing leading '/' from absolute path names
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx
default:user::rwx
default:user:test:r--
default:group::rwx
default:mask::rwx
default:other::rwx

oh by the way, the test machine I play around is a suse linux machine

my-xftp0:~ # cat /proc/*version
Linux version 2.6.32.12-0.7-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 2010-05-20 11:14:20 +0200

...weird no?

Sometimes ACL support is defined on the superblock, even if /proc/partitions , /etc/mtab , /etc/fstab , tune2fs , etc do not explicitly report ACL support.

What's the output of:

dumpe2fs /dev/sda8 | grep -i 'mount options'

Here's the output from my test machine

my-xftp0:~ # dumpe2fs /dev/sda8 | grep -i 'mount options'
dumpe2fs 1.41.9 (22-Aug-2009)
Default mount options:    (none)
my-xftp0:~ # date
Thu Dec 22 10:46:26 MYT 2011
my-xftp0:~ # 

and the output from prod machine

[root@H99A100 dev]# dumpe2fs /dev/sda1 | grep -i 'mount options'
dumpe2fs 1.39 (29-May-2006)
Default mount options:    user_xattr acl

That's strange indeed. Perhaps some SUSE-specific thing is messing with ACLs.

The remount command does not usually produce any output so you were assigning ACLs after explicitly enabling them on that filesystem. I'm just not sure why it isn't showing "acl" in the superblock or in the filesystem options.

Yeah, that is weird...never mind thanks for your help though. It is confusing as it is, ACLs.

Please close this thread. There's no way the client will agree with ACL since it involves on setting the FS to be mounted with ACL support, then masking the user's access for the FS and everytime they see the + sign at the end of the FS, someone will go crazy.

Please close this thread