[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ACL hierarchy & getfacl/setfacl ACE Ordering possibly fixed doing...
Sorry I kinda cluster-frelled this email with probably two different threads
:) I was writing the first ACl hierarchy question while I think I fixed the
ACE ordering LOL
This question is a little out of blue I suppose, but i'm looking to
hopefully setup a system of directory permission access so I can have:
/home/user1
/home/user1/subuser1
/home/user1/subuser1/subuser1subuser1
/home/user1/subuser1/subuser1subuser2
/home/user1/subuser2
Type of heirachy where the user1 can access everything under his
/home/user1, subuser1 can access everything under his subuser1 home
directory, and subuser2 acccess to his directory and etc.
What type of configuration would need to be implemented so that ACLs would
handle all of this.
Basically I want the "controlling" account "user1" to be
able and access any "subuser1", "subuser2" files, where "subuser1" also has
access to his child accounts "subuser1subuser1", and "subuser1subuser2"
(user1 could also access these/his "children's"-"child" accounts)
The runtime problems I've had so far include when creating "files" - the
executable bits often get set automatically (based upon defaults for a
directory) - but if I dont' have the default x then a sub directory that
gets created won't be able to be accessible as it doesn't have the +x bit.
are there any specific umask flags or something I could set in the FTP
Daemon or the shell profile which would remedy this?
also If I go through and find ./ -type f -print0 | xargs -0 chacl files then
it'll totally screw up "individually" delgated permissions for files if I
were to have a means of "updating" permissions
are there better ways to keep permissions?
I recently started messing with the setfacl and getfacl commands as well,
the recent quote
"Andreas' code, however, does _not_ require the ACEs to be ordered from
the user - unsurprisingly, his code sorts them.
However, in the port of setfacl and associated missing libacl functions,
it appears that something has gone wrong because unless the
ACEs are in the correct order when given as an argument to setfacl,
it gives an error message."
I sure can't see where it sorts them :) It appears that the find_acl
functions just look for the particular hosts rather than being dependant on
the ordering...
I do however see a ./include/acl.h:extern void acl_entry_sort (acl_t __acl);
which could be called in the do_set() function - though I'm not sure if that
is an appropriate place - I inserted a
acl_entry_sort(acl);
infront of:
error = acl_check(acl, &which_entry);
and a
acl_entry_sort(default_acl);
infton of:
error = acl_check(default_acl, &which_entry);
in:
int
do_set(
const char *path_p,
struct stat *st, ....
in the do_set.c
and I'm not getting the ordering error any longer... ( i havn't tested it
enough to see if this really cleaned it up sorry - just toying with XFS at
the moment :)
I replicated the previous post on the ACE bug:
[root@localhost er1c]# getfacl 1111
# file: 1111
# owner: root
# group: root
user::rwx
group::rwx
other::rwx
user:er1c:rwx
mask::rwx
default:user::rwx
default:group::rwx
default:other::rwx
default:user:er1c:rwx
default:mask::rwx
[root@localhost er1c]# setfacl -d -x u:er1c 1111
lt-setfacl: 1111: Resulting default ACL
`user::rwx,group::rwx,other::rwx,mask::rwx': Missing or wrong entry at entry
4
after applying the "patch":
[root@localhost er1c]# /usr/bin/setfacl -d -x u:er1c 1111
[root@localhost er1c]# getfacl 1111
# file: 1111
# owner: root
# group: root
user::rwx
group::rwx
other::rwx
user:er1c:rwx
mask::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx
Cheers & Thanks,
Eric