Hi Experts,
I have set access control to a directory which is under / as /proj1 and set the access to user1 as below
Once I logging as user1 I am able to create and modify the file which is created by user1 however I am unable to edit / modify the file which is own by root.
Please help!
Thet setfacl operation specified operates only on the directory, not anything below it. New files in that directory will inherit the properties you set on the directory, but existing files will be unchanged.
Thanks otheus
I have created file after setting the access control and still its now allowing the user to modify the newly created files
Its now or not allowing the user to modify the newly created files?
Yes, it�s not allowing the user1 to modify the files which are own by root.
so, problem solved?
No not as i said its now allowing to modify the files which are own by root
Your original request:
Your updated statement:
What is it you want?
Sorry , that was typo i mean its not allowing to modify / edit from user1
The umask might be coming into play. What's your umask? Change it to 000 and try again.
I don't think the umask should help.
User1 is granted read and write access only for the directory itself which means he can create, rename and delete files there, even those that do not belong to him.
Files in that directory keep their permissions so it is expected for user1 not to be able to directly modify root owned files content.
The ACL mask in a directory represents the "maximum" permissions a file can have -- it does not force new files to have those permissions. It's not like umask.
I don't understand it that way.
The ACL mask parameter when set to a directory apply to permissions set to that directory, not to existing or new files inside it.
There are two differing acl schemes floating around. We are discussing the older scheme that is in use on Solaris ufs file systems. Setting an acl on a directory does not propagate to any pre-existing files under that directory. If a file is created in a directory with an acl set, that acl is not automatically applied to the file. You can't set a file's umask with a setfacl or by any other technique. Files do not have umasks, processes have umasks.
This form of acl does have a "mask" concept. It is intended to enable a non-acl aware program to be able to interact with a file that has acls. The file owner is immune from the mask and so is the "world" (or "other"). These two classes of users are clearly defined in an identical fashion whether or not you use acls. But an acl can specify various other groups and users and these folks don't make sense to a non-acl aware program. So the idea is to use this "mask" concept. For example, if a program uses the chmod() system call to remove group execute permission, execute permission is removed from the mask. This is a controversial idea, but it does make some sense... older programs can continue to run.
If you still don't understand the mask concept, just do this:
Whenever you change the permission on a non-owner user or a group with a setfacl command, specify the -r option to recompute the mask and other than that leave the mask alone.
Sorry, a word was missing in my last post that was making it confusing. I was already understanding the mask concept the way you describe it.
The bottom line is, regardless of the "umask vs mask" and "wrx vs rwx" typos in the initial command posted, the behavior the OP is observing is correct and there is no way to directly achieve what he wants.
ZFS NFSv4 ACLs wouldn't help either in that case as existing files permissions aren't affected by the inheritance flags.
In any case, assuming the directory ACL are properly set, it would be possible for the user to overcome the limitation by first renaming the file to edit, then copying that file to the original name and finally removing the copy. eg:
$ id
uid=xxxxx(jlliagre) gid=xxxxx(jlliagre)
$ su
...
# mkdir d
# pe setfacl -r -m user:jlliagre:rwx d
# date > d/f
# getfacl d
# file: d
# owner: root
# group: root
user::rwx
user:jlliagre:rwx #effective:rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
# getfacl d/f
# file: d/f
# owner: root
# group: root
user::rw-
group::r-- #effective:r--
mask:r--
other:r--
# ^D
$ cd d
/tmp/mnt/d
$ ls -l
total 2
-rw-r--r-- 1 root root 30 Jul 4 11:32 f
$ date >> f
/bin/ksh: f: cannot create
$ mv f f1
$ cp f1 f
$ rm -f f1
$ date >> f
$ ls -l
total 2
-rw-r--r-- 1 jlliagre jlliagre 60 Jul 4 11:32 f