> From: Garrett D'Amore > Sent: Wednesday, October 11, 2017 2:11 PM > > The security question is whether there is ever a need to suppress access to > the cwd. I think there are several cases where this is absolutely valid.
It would be a security question if there wasn't a simple and easy alternative method to obtain the exact same information 8-/. Is there really a point in having a deadbolt on the front door when you can walk 10 steps to the side and stroll right through the unlocked kitchen door? > I do believe Joerg is right here — this represents, as far as I am concerned, > a > bug in the Samba code. There was indeed a bug in the code; it crashed when getcwd failed. That's how we found the difference in behavior between illumos and other operating systems. That bug has been fixed, and there are no longer any bugs (that we know of) in the samba code regarding this. The samba code relies upon knowledge of the current working directory in order to implement security policy. If it is unable to determine the current working directory, it refuses to perform certain functions. It in no way assumes getcwd will succeed, or that it will always know what the current working directory is. It simply makes decisions based on whether or not it does. Of course, this is undesirable behavior for us, as this lack of functionality is debilitating to our users. And the failure of the getcwd call is really not providing any security for the system, as if samba just knew enough to walk 10 steps over to the kitchen door, it could quickly and easily get the exact same information that getcwd is refusing to give it. > In fact, processes can even live without a valid cwd — for example if > someone forcibly unlinks the directory. This isn’t even all that unusual — I > have left my own shells in that on occasion. Well, obviously nonexistence of a cwd is a different state than inability to read the path of an existing one. Interestingly, it seems getcwd() returns ENOENT in that case, which isn't even documented as a possible error value in getcwd(3c). The bottom line is that other major operating systems, not only Linux and the BSD's, but also Solaris 11 and the most recent 10, no longer return access denied for the getcwd call if a component of the path lacks read permission. The latest POSIX standard has changed the definition from SHALL to MAY for that error code. Given under illumos the same information is available via a different avenue, it's hard to buy a "but the security" argument for not updating illumos to the same behavior. I understand there are potentially other things to consider in illumos such as zones, etc, but presumably those same considerations were made in Solaris for the change, and while I most certainly would never be one to advocate let's just play follow the leader with Oracle, my understanding is that those changes were made by Casper Dik, and I definitely would trust he appropriately evaluated them before they were implemented. ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T1bf578bf66b8b8b0-M64ba4a543e504dbfc7ac70cf Powered by Topicbox: https://topicbox.com
