In message 19995518185446334@ix.netcom.com, sirbruce@ix.netcom.com writes:
On 05/05/99 15:53:45 you wrote:
In message 7F608EC0BDE6D111B53A00805FA7F7DA03A83938@TAHOE.netapp.com, "M
uh
lestein, Mark" writes:
A mixed qtree already works exactly as you want it to. In a mixed qtree t
he
security of a file is based on the last security-setting operation. If an
A
CL is set which denies you access, but you still need to do something with a fi
le,
then as root you can change the security on any files/dirs in that qtree
(using
chmod, chown, or chgrp), which changes the security-style to UNIX. After
that,
No, you shouldn't be able to chmod or chgrp it. (Read what you write on this subject further down.) You should be able to chown it. That was my point.
Ok, so far I've read this alot. No maybe I'm missing something 'cause I get the following errors trying to put it into practice.
What errors? These are exactly correct.
Here's a test on a directory w/ NTFS permissions allowing only full control to the owner:
In other words, you've told NTFS that Administrator can't read the directory or change permissions. All Administrator can do is assume ownership.
So how does root take ownership...?
root@jagular: fs0/home/kelleher [130] # root@jagular: fs0/home/kelleher [130] # ls -ald test_dir drwx------ 2 kelleher users 4096 May 5 14:47 test_dir root@jagular: fs0/home/kelleher [131] # root@jagular: fs0/home/kelleher [131] # ls -al test_dir test_dir: Permission denied total 8
This is correct; root on UNIX will map as Administrator in the NT realm, so it can't read the directory.
root@jagular: fs0/home/kelleher [132] # root@jagular: fs0/home/kelleher [132] # chown 755 test_dir chown: test_dir: Not owner
Firstly, you should have done chmod, not chown.
What....? That makes no sense. As you state above. I can't change the permissions, but I should be able to "take ownership", correct?
Secondly, this would be correct... Administrator (root) does not have permission to change the file permissions.
root@jagular: fs0/home/kelleher [133] # root@jagular: fs0/home/kelleher [133] # chown root test_dir chown: test_dir: Not owner root@jagular: fs0/home/kelleher [134] #
This should have suceeded, if I understand the model correctly. I'm not sure why it didn't; perhaps it's a bug?
So why are you telling me that, "These are exactly correct."
I can however su to the UNIX user, chmod it, and then get access to the file:
root@jagular: fs0/home/kelleher [134] # su kelleher jagular% jagular% chmod 755 test_dir jagular% jagular% exit jagular% root@jagular: fs0/home/kelleher [135] # root@jagular: fs0/home/kelleher [135] # ls -al test_dir total 72 drwxr-xr-x 2 kelleher users 4096 May 5 14:47 . drwxr-xr-x 25 kelleher users 32768 May 5 15:25 .. -rwx------ 1 kelleher users 0 May 5 14:47 test_file root@jagular: fs0/home/kelleher [136] # root@jagular: fs0/home/kelleher [136] #
Is this what you mean?
This all makes sense.
I thought you just said something which should have succeeded didn't and that it might be a bug? Do you read what you type?
I'm trying not to be rude, but you just sent me email stating I wasn't seeing a problem and then point out there might be a problem.... Less than helpful. I'd prefer consistently wrong information in the future. :)
thanks anyway,
jason
those files follow regular UNIX rules, which allows root full access. If
the
user wants to put an ACL back on afterwards, no problem.
We have found that using ACLs in a mixed qtree can be helpful in a number
of
situations. That's because ACLs are enforced even for NT Admins and root.
For
example, we found that some files were being accidentally deleted by root
/Admin
users, so we put an ACL on those files which allows only READ access to a
ll
users. That prevents deleting, even by root or NT Admins. Of course, if w
e
actually want to delete the files we just change the permissions to allow
that,
since in a mixed qtree both root and NT Admins have a special dispensatio
n
tochange the permissions.
Sounds like the problem is too many people with root/Admin access. Your solution only requires these people to take an extra step (give themselves the permissions) before they accidentally mess something up. If I were you I'd work on getting rid of their access. (Not that it's an easy thing to do.)
In my experience many people are unwilling to take this approach, for reasons I can't quite fathom. They would much rather let incompetent people continue to work for them and spend effort trying to keep them from shooting themselves in the foot rather than spending the time to make them competent and/or getting another employee.
Bruce