linux-ext4 - Re: inline

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <loom.20140210T125618-759@post.gmane.org>
Date:	Mon, 10 Feb 2014 12:06:05 +0000 (UTC)
From:	Ian Nartowicz <claws@...towicz.co.uk>
To:	linux-ext4@...r.kernel.org
Subject: Re: inline_data feature

Zheng Liu <gnehzuil.liu <at> gmail.com> writes:

> 
> On Sun, Feb 09, 2014 at 03:45:12PM +0000, Ian Nartowicz wrote:
> > Ian Nartowicz <claws <at> nartowicz.co.uk> writes:
> > 
> > I copied the contents of /home onto the new partition.  fsck reports, and
> > other utilities confirm, that symlinks with targets of 60 characters or
> > longer were corrupted by the copy.  For example, a truncated symlink:
> > All That You Can't Leave Behind.m3u -> /data/cd/U2/All That You Can't Leave
> > Behind/playlist.flac.m
> > 
> > If I create the same symlink with ln, it appears OK until I unmount and
> > mount the partition, then it shows truncated.  fsck doesn't like it but is
> > unable to correct it.
> 
> That would be great if you can provide some steps to reproduce this
> issue.  I write a simple script to try to reproduce it, but I couldn't
> hit the problem.  Am I missing something?
> 
>   #!/bin/bash
> 
>   mkdir test
>   cd test
>   filename="ALL-That-You-Can't-Leave-Behind.m3u"
> 
>   echo "hello" > $filename
>   ln -s $filename symlinkfile
>   readlink symlinkfile
> 
>   newdir="data/cd"
>   mkdir -p $newdir
>   cp -d symlinkfile $newdir
>   readlink $newdir/symlinkfile
> 
> Thanks,
>                                                 - Zheng
> --

To reproduce this on my system, the full path for $filename needs to be
longer than 60 characters.  That seems to be the only requirement.  Create
the symlink, unmount, mount, and the target path of the synlink is truncated
to 59 characters and hence the link is broken.

fsck reports those symlinks as follows:
Symlink /iann/test.m3u (inode #139) is invalid.
Clear<y>? no
Entry 'test.m3u' in /iann (8001) has an incorrect filetype (was 7, should be 0).
Fix<y>? no

If I try to clear or fix, it just leaves behind damaged inodes which fsck
can't fix.

--ian

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html