Yeah, I think the Samba folks don’t like illumos that much, because we have our own SMB implementation that *isn’t* Samba. There is other history there as well, which I won’t get into.
Having said that, it would be pretty easy to install a shared library shim that overrides getcwd() with one that reads proc(). There are some potential downsides to baking in /proc reading. a) The /proc file system has to be accessible. I’m not sure that this is universally the case with zones, and certainly not with chroot, for example. b) In a chroot environment, getcwd should understand that the root terminates at the chroot; the /proc read today may or may not be aware of this. c) Likewise, I’m not sure the /proc read is “zone” aware. For my 2c, I think a better approach would be a system call. The system call should understand zone roots, and chroot. I’m not sure that there are not other security implications associated with this — I can’t think of any reason that the cwd ever should be suppressed from a process, but that doesn’t mean that such a reason doesn’t exist. At the end of the day, perhaps you should ensure that your Samba daemon actually has search rights on the intervening directories. You can give them that (X bit) without giving them other access (R and W bits). - Garrett On Tue, Oct 10, 2017 at 6:03 AM Youzhong Yang <[email protected]> wrote: > We had similar issue when we upgraded to Samba 4.6.5. The so-called > security patch CVE-2017-2619 caused all the pain. > > If you don't care much about this security patch, then patch your Samba > code, disable it, then you will be happy again. > > The Samba folks tried to persuade everyone who reported a Solaris/illumos > related bug to move to Linux/FreeBSD, :-) > > > On Mon, Oct 9, 2017 at 6:41 PM, Brian De Wolf <[email protected]> wrote: > >> We have some file servers running OmniOS that are serving their shares >> using Samba rather than the in-kernel server. We recently updated >> Samba, experienced crashes, and worked through the problem with Samba >> developers [1]. >> >> A summary of the problem is that newer versions of Samba use >> getwd/getcwd/realpath to track where the Samba process is so that it >> can't be tricked into operating in a directory outside of the share's >> parent directory. This breaks down on Illumos platforms because getcwd >> observes filesystem permissions- if one of the parent directories is >> unreadable to the process, the process can no longer call getcwd >> successfully. This originally caused the server to panic and >> completely die, but even with patches, only certain operations are >> available when getcwd is broken (read-only, essentially). >> >> The other main platforms (Linux and FreeBSD) don't have this issue. >> Annoyingly, Illumos seems willing to provide this information without >> constraints, but only if you readlink("/proc/self/path/cwd") instead. >> >> Is it crazy to ask for getcwd's behavior to be changed? It's >> technically allowed by POSIX to fail like this (which I suspect is to >> allow for naive implementations that have to walk the filesystem), but >> there doesn't seem to be an alternative for a process that wants to >> validate its cwd. >> >> Is there something I'm missing that Samba could use instead? I've >> played with using LD_PRELOAD to replace getwd/getcwd with reading proc, >> but that doesn't feel like a sustainable solution. >> >> [1] https://bugzilla.samba.org/show_bug.cgi?id=13027 > > *illumos-discuss* | Archives > <https://illumos.topicbox.com/groups/discuss/discussions/T1bf578bf66b8b8b0-Md0848df536260d1a45737503> > | Powered by Topicbox <https://topicbox.com> ------------------------------------------ illumos-discuss Archives: https://illumos.topicbox.com/groups/discuss/discussions/T1bf578bf66b8b8b0-M93f586375e7698d23a16498a Powered by Topicbox: https://topicbox.com
