Unix permission coexistence with posix acl

[William Muriithi]

Hello pals,

Curious if any of you know how the old Unix ACL interacts with posix ACL. I
mean, if you have a directory that is using both ACL, which one does the
system use to enforce the permission? I am suspecting both are checked but
one supersede the other, kind of the way Unix ACL are checked before
SElinux. I have googled this morning but don't seem to be having any luck.

Case in point, I have a jboss folder that I need to manage through a group.
The problem is, if they delete the tmp directory, on restarting jboss, the
directory end up owned by root. Shouldn't it be owned by jboss, being the
default user?

I should say jboss  is currently running as root, something which I plan to
fix by forwarding default port to 443, so don't shot me for that mistake

[root at dev2-yyz-int ~]# getfacl /opt/application/jboss/server/default/
getfacl: Removing leading '/' from absolute path names
# file: opt/application/jboss/server/default/
# owner: jboss
# group: developers
# flags: -s-
user::rwx
group::rwx
group:developers:rwx
mask::rwx
other::r-x
default:user::rwx
default:user:jboss:rwx
default:group::rwx
default:group:developers:rwx
default:mask::rwx
default:other::r-x

[root at dev3-yyz-int default]# ls -al
total 80
drwxrwsr-x+ 10 jboss developers 4096 Jan 30 12:00 .
drwxrwsr-x+  5 jboss developers 4096 Feb 16  2012 ..
drwxrwsr-x+  4 jboss developers 4096 Jan  8 12:47 conf
drwxrwsr-x+  5 root developers 4096 Feb 16  2012 data
drwxrwsr-x+ 10 jboss developers 4096 Jan 29 16:35 deploy
drwxrwsr-x+  5 jboss developers 4096 Apr 11  2012 lib
drwxrwsr-x+  2 jboss developers 4096 Jan 30 00:00 log
drwxrwsr-x+  2 jboss developers 4096 Jan 14 16:16 sslcerts
drwxrwsr-x+  4 root developers 4096 Jan 30 14:11 tmp
drwxrwsr-x+  3 root developers 4096 Jan 30 12:00 work

Shouldn't user be jboss on creating a new tmp directory? Anything you can
think that I can do to get those three directory  adopt the parent
directory permission?

Regards

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20130130/037ef783/attachment.html>