We have some files are under 744 permissions and the the owner is say owner1 and group1.
Now we have another user owner2 of group2, owner2 can remove files of the owner1 and the permission of those files are 744, unix admin told us he did some config at his side so we can do that.
So I just wondering how this can be setup? Note that both owner1 and owner2 also belong to other groups and possibly owner1 in group2 and owner2 in group1 also...but files under 744 can be deleted is what I don't know how that happened ?
Thanks for all the replies !!
I guess ceubank gave the answer...
but looks like getacl or getfacl are not available on AIX 5.3.
So basically that means, what we see in the file permission bits that we deal with everyday, may not be what we think, the unix admin could do something there and over write the user permission settings.
This is what happened, it took me quite some time to remove the company confidential information from the screen cuts below:
ACLs can overwrite POSIX if that is what you are asking. Sometimes if your servers are running any kind of directory services and LDAP they will put ACLs in the file system by default, and they will be set by default as what the default settings will most likely be.
I have seen this in OS X and in SuSe Linux, but anything outside of those two I don't have much experience with ACLs.
ACLs can be a pain, especially when used with nested folders, but when they work they are a great. I did notice that on the newest version of OS X (which I know is it's own version of Unix) has some custom default ACLs "everyone:deny" on certain folders in every user's home directory, by default.
Hi ceubank, would you please be able to explain what does this means interms of the last options colomn? Does rw means that the current user who issue this mount command has rw access to the file system(/apps/z0/log) even the files in there belong to someone else and permissions are say 700 ?
Thanks in advance.
f8fmil: /apps/z0/log/new2/Jr>mount -o acl
node mounted mounted over vfs date options
-------- --------------- --------------- ------ ------------ ---------------
/dev/hd4 / jfs2 Nov 18 15:52 rw,log=/dev/hd8
/dev/hd2 /usr jfs2 Nov 18 15:52 rw,log=/dev/hd8
/dev/lvappz0log /apps/z0/log jfs2 Nov 18 15:53 rw,log=/dev/lg_appvg01
No, it just means the filesystem is mounted as read-write, letting people read and write according to their normal permissions, as opposed to read-only.
Without ACL's, directory permissions are the only thing describing who can and can't delete files. File permissions and ownership are irrelevant. Observe:
$ mkdir tmp
$ touch tmp/notouch
$ chmod 000 tmp/notouch
$ sudo chown root:root tmp/notouch
# You can delete a root-owned file with 000 permissions, if it's in your dir!
$ rm tmp/notouch
---------- Post updated at 10:07 AM ---------- Previous update was at 09:49 AM ----------
I had to do some testing to figure it out, but the sticky bit could help do what you want. It's also known as the restricted-deletion bit. On supported systems&filesystems, inside a directory with it set(with chmod +t), users cannot rename or remove files that don't belong to them. It's often used for /tmp.
(Note that this protection is short-circuited if the user in question actually owns the directory. Have it owned by root or something.)
to allow others to delete a file using ACLs , you can view these permissions with ls -le to see the ACL flags set.. if you have a directory and you want to allow people to delete things in it you would do others allow delete_child.
Actually I'd like to say sorry for dragging so many people into this...I just found out the directory owner was changed to the userid just one second before that I did the delete, that's why I got the impression why I could delete someone else's file without the permission being set...that was silly I should have checked back the dir permission first for the doubt.
