lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 22 Oct 2013 13:46:08 -0500
From:	Steve French <smfrench@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>
Subject: Fwd: 3.11+ Problem with cifs links, bisected

---------- Forwarded message ----------
From: Steve French <smfrench@...il.com>
Date: Tue, Oct 22, 2013 at 1:45 PM
Subject: Re: 3.11+ Problem with cifs links, bisected
To: Joao Correia <joaomiguelcorreia@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Pavel Shilovsky
<pshilovsky@...ba.org>, Jeff Layton <jlayton@...hat.com>


I wonder if this is a similar issue to what I fixed with
(Pavel's patch assumed that these reparse points
were NTFS symlinks but they could be other types
of reparse points such as the new "NFS symlink"
format)

commit c31f330719b7331b2112a5525fe5941a99ac223d
Author: Steve French <smfrench@...ibm.com>
Date:   Sat Sep 28 18:24:12 2013 -0500

    do not treat non-symlink reparse points as valid symlinks

    Windows 8 and later can create NFS symlinks (within reparse points)
    which we were assuming were normal NTFS symlinks and thus reporting
    corrupt paths for.  Add check for reparse points to make sure that
    they really are normal symlinks before we try to parse the pathname.

    We also should not be parsing other types of reparse points (DFS
    junctions etc) as if they were a  symlink so return EOPNOTSUPP
    on those.  Also fix endian errors (we were not parsing symlink
    lengths as little endian).

    This fixes commit d244bf2dfbebfded05f494ffd53659fa7b1e32c1
    which implemented follow link for non-Unix CIFS mounts

    CC: Stable <stable@...nel.org>
    Reviewed-by: Andrew Bartlett <abartlet@...ba.org>
    Signed-off-by: Steve French <smfrench@...il.com>





On Tue, Oct 22, 2013 at 8:12 AM, Joao Correia
<joaomiguelcorreia@...il.com> wrote:
>
> Hello list
>
> I've been having a problem mounting windows shares with deduplicated
> files (from windows 2012 deduplication), as they would show up either
> garbled or 'ls' would complain it couldn't follow them.
>
> Git bisect blames the following:
> commit b42bf88828cde60772dc08201d0a4f1a0663d7bc
> CIFS: Implement follow_link for SMB2
> Author: Pavel Shilovsky <pshilovsky@...ba.org>
>
> dmesg doesn't complain at all.
>
> Reverting the commit fixes the problem and the deduplicated files can
> be opened perfectly, but more recent updates have been made on top of
> that one and i think it can't be cleanly reverted on current -next
> trees (or rcs)
>
> If i'm not mistaken, windows 2012 treats deduplicated files as links,
> but that's just what i can surmise from using it, i haven't read
> anything about it's internals yet.
>
> I've CC'ed the persons mentioned on the patch, please forward it to
> anyone else that might be interested and is not on the lkml.
>
> Thanks,
> Joao Correia




-- 
Thanks,

Steve



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ