RaiseAwarenessToday

Start tutoring students.





============================================================================================================================ On Sat, 31 Oct 2009, Ron Loftin wrote: ELrepo site, I can mount an NTFS filesystem, and when I type "mount" with no options the output tells me that the target filesystem is mounted read-write. However, when I try to create a file on that filesystem as root, I get a "Permission denied" error, which leads me to think that I'm missing something here. Stupid question: BEFORE you mount, what are the permissions on the mount point? Those permissions can affect what you can do with the mounted filesystem. Once you mount the filesystem it's awfully hard to figure out what the problem is because the original mount point permissions are hidden... That one has gotten me before, but a wiser SA than myself warned me before I ever came across it, so I didn't spin my wheels _too_ long looking for the problem! That would have been a real hair-puller otherwise. I don't know whether current Unix/Linux systems behave in the same manner, but SunOS/Solaris used to. -- Curt Mills, WE7U hacker at fluke dot com Senior Methods Engineer/SysAdmin "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U "The world DOES revolve around me: I picked the coordinate system!" Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email. On Thu, 25 Feb 2010, Marion Hakanson wrote: It's not easy to get them right, and usually the hardest task is in figuring out what the users want, so we don't use them unless the users' needs cannot be met using traditional Unix/POSIX permissions. We've got a web GUI that hides the complexity from end users, pretty much they see a list of files/directories, and pick users/groups with read only or read/write. We offer access to central user/group space via CIFS (currently samba in s10, with an eye towards opensolaris/in-kernel server), web, scp/sftp, kerberized NFSv4, and interactive unix login. The web server enforces ACL's, so users can restrict their web content by them. We've had a similar environment based on DCE/DFS for over 10 years (we're just about ready to shut that down, having completed migrating everything over) and our users have become quite acclimatized to the flexibility that this gives them to set access control once and have it respected regardless of access protocol. and using inheritance to propagate them to any new items which are added to shared areas. What protocols/access methods are used to get to the underlying zfs filesystem? The main ACL problem we've having now (having resolved most of them, yay) is interaction with chmod() and legacy mode bits, and the disappointing ease with which an undesired chmod can completely destroy an ACL. I finally ended up having to preload a shared library that disables chmod() into samba, which resolved our issues for CIFS. I still haven't found a way to keep users' ACL's from being wiped by rogue non-ACL aware command/utilities (including, as it turns out, Solaris' own chgrp command). Unfortunately, there's currently no global way to prevent manipulation of legacy mode bits from destroying ACL's. I've been working around particular instances of the problem (such as the preloaded shared library for samba, or using "chown :" rather than chgrp), but it's a losing battle. There are 40 odd years of non-ACL aware stuff out there, it's intractable to try and fix it all on a case by case basis. Given ZFS's description as having a "pure acl" model, it really seems there should be some way to prevent those ACL's from getting wiped out at the drop of a chmod. The scripting also (sorta) covers the problem that most backup and file transfer utilities are not capable of backing up and restoring the NFSv4-style ACL's on ZFS. We have a central Netbackup deployment. Supposedly it supports ZFS ACL's, although I've never actually tested that. I suppose I should at some point 8-/. If we can't find some clean way to maintain ACL sanity, we might have to start storing ACL's in metadata files (maintained in lockstep by our web control app), and having a job run around and restore broken ACL's on files/directories on an ongoing basis. That would be pretty kludgy :(, but better than sensitive data suddenly becoming world readable because somebody's favorite editor feels the need to chmod a file after creation to match the permissions it thinks it should have had based on the umask. Talk about a security deficiency . Thanks for the info... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen ... @csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs- ... @opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss