RFC: CVE-2017-2619 fix breaks accessing previous versions of directories with snapshots in subdirectories of the share

Ralph Böhme slow at samba.org
Fri Jul 7 15:08:59 UTC 2017


On Fri, Jul 07, 2017 at 07:58:10AM -0500, Scott Lovenberg wrote:
> > 
> > On Jul 7, 2017, at 07:12, Ralph Böhme via samba-technical <samba-technical at lists.samba.org> wrote:
> > 
> > Hi!
> > 
> > As explained in <https://bugzilla.samba.org/show_bug.cgi?id=12885>:
> > 
> > With shadow:snapdirseverywhere=true and a snapshot directory that
> > 
> > * is a subdirectory of a share
> > 
> > * and that contains a snapshot directory
> > 
> > we fail the symlink check in the new function non_widelink_open() because
> > parent_dirname() cuts off the subdirectory name leaving only the @GMT stanza
> > which is then interpreted by the called functions as being relative to the
> > parent directory which it isn't.
> > 
> > The simplest fix as far as I can see is to leverage the fact that (given the
> > system defines O_DIRECTORY) we know when we're called for a directory, so we can
> > just directly chdir() into the path passed by the caller.
> > 
> > Can we rely here on O_DIRECTORY? Linux has it, FreeBSD has it, Solaris has it
> > and we probably don't care about the rest.
> > 
> > The subsequent security check done in check_reduced_name() should continue to
> > work with this change.
> > 
> > I've just fire of a private autobuild with the patchset and will follow up with
> > the results (fingers crossed :) ).
> > 
> > Cheerio!
> > -slow
> > <look>
> 
> Out of curiosity, does this break MSDFS links since they're internally handled
> like symlinks IIRC?

la, la, la, I can't hear you, la, la, la. ;)

No, I don't think so. The breakage with shadow_copy2 is triggered by the logic
that tries to figure out the corrent (tm) location of the .snapshots directory.

Cheerio!
-slow



More information about the samba-technical mailing list