Huge Security Problem

[Kalagan]

Unless I am missing something, it seems like any user can throw away any folder they want to, even if they have no R/W Permissions at all, on an Xsan Drive or even a Local Drive!!

Is this correct? Is there anyway to stop this huge security problem?

I have been searching for hours on many Unix and OS X Sites, but I have not been able to find any relevant information about this issue.

Help
Kalagan

[dgf]

How are you managing your users? In our OD environment we do not have these issues. Our Xsan 1.1 clients are 10.4.2, but all authenticate against a 10.3.9 OD Master-Replica database. Mounting SAN volumes both via Xsan and shared over afp/smb have the same predictable results as long as the users are OD users. Local NetInfo accounts are a different story though.

[Kalagan]

My latest test has been with a Netinfo Local User. I have not tried it yet with an OD User. Will the results be the same?

How well is your Xsan Environment working setup that way? I though that was not a suggested configuration? Are you running to the problem where Read Only Quicktime files will not play from an AFP Shared Xsan Volume? What version of Quicktime are you using?

Thanks
Kalagan

[szumlins]

[dgf]

My Xsan environment has always been OD authentication for the reasons that szumlins states. The only permissions based issue I run into, is that on Xsan volumes, newly created directories have the group designation of the user's primary gid, NOT the designation of the parent directory, as it should. But this should only affect those of us that segment our users into differing groups AND have some users that are members of several groups. I have some workarounds, but I wish the gid designation behaved like it should.

It has always been my impression that while OD is not listed as a requirement, it should be.

[Kalagan]

I have been able to trash Folders that I didn't create, that I do not own and that I don't have any Access to at all (CHMOD 000). Example; I can step into the Users Folder and Trash lets say the "Music" Folder from another Users Account. I am asked for an Admin Password, but all I need to do is provide the Admin Password for the Account I am in, not the Admin Password for the Owner of the Folder. I just created a new Standard Account and repeated the same process, with the same result. I can trash another Users Music Folder, by providing an Admin Password for an account that is not the Owner of the Folder. That seems a little weird.

I briefly looked into UUCH and SUCH, but those seem like they lock the entire folder, so nothing can be added to it? That doesn't seem like the best solution. Will the sticky bits help here? Sticky Bits seems like they can control the contents of the folder, but not the folder itself and I have heard that they don't seem to work on Xsan Volumes. Is that correct?

This one is a little baffling.

Thanks
Kalagan

[dgf]

[Kalagan]

My current tests haven't been on an Xsan Volume, but a friend of mine has run the same test on Xsan Volumes and got the same results. Read/Write permissions seem to work. If you don't have Read or Write then you can't access the folder. But you can throw it away and empty the trash.

My test I referred to eariler, was on our local drive and that test ended up with the same results. I ran ls -ln and the Music Folders were owned by the correct User Admin 501 in one case and Admin User 502 in the other. But I was still able to trash the Music folder of Admin User 501 while I was logged in as Standard User 503. I was asked for an Admin password, so I entered the Password for Admin User 502. I was then allowed to put the Music Folder of Admin User 501 in the trash and empty the Trash.

Sounds like a big gapping whole in the security of OS X?

Kalagan

[aaron]

[Kalagan]

aaron,

why should you keep all users in the same primary group? I have been doing this to keep it simple for me, but is there a more important Xsan reason?

thanks
Kalagan