linux-ext4 - Re: [ANNOUNCEMENT] Linux POSIX file system test suite

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.62.0804070234350.25240@tamago.serverit.net>
Date:	Mon, 7 Apr 2008 02:51:15 +0300 (EEST)
From:	Szabolcs Szakacsits <szaka@...s-3g.org>
To:	David Chinner <dgc@....com>
cc:	ntfs-3g-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org,
	fuse-devel@...ts.sourceforge.net, zfs-fuse@...glegroups.com,
	linux-ext4@...r.kernel.org
Subject: Re: [ANNOUNCEMENT] Linux POSIX file system test suite


On Fri, 4 Apr 2008, David Chinner wrote:
> On Fri, Apr 04, 2008 at 10:33:30AM +1000, David Chinner wrote:
> > On Thu, Apr 03, 2008 at 12:29:47AM +0300, Szabolcs Szakacsits wrote:
> > >   The test must be run as root user and requires a few basic Perl modules.
> > 
> > And openssl, it appears.

Openssl is replaced with md5sum+cut in the CVS. 

It would be also nice to eliminate the Perl dependency ...

> > The current xfs-dev tree:
> > 
> > Failed Test                    Stat Wstat Total Fail  Failed  List of Failed
> > -------------------------------------------------------------------------------
> > /root/posix/tests/chown/00.t                171    2   1.17%  84 88
> > /root/posix/tests/symlink/02.t                7    2  28.57%  6-7
> > Failed 2/184 test scripts, 98.91% okay. 4/1950 subtests failed, 99.79% okay.
> 
> Symlink tests 6 and 7:
> 
> expect 0 symlink ${name256} ${n0}
> expect 0 unlink ${n0}
> 
> Test 6 is failing with ENAMETOOLONG
> Test 7 is failing (correctly) with ENOENT because test 6 failed.
> 
> So there's only one failure here, and that is that that we're rejecting
> ${name256} as too long. I think that getname() is doing this. Seems sane
> to me to disallow symlinking to pathnames that can't be constructed,
> even if POSIX apparently allows it.

As Christoph noted, I also noticed XFS is unique in this behavior.

> Chown tests 84 and 88:
[...] 
> So, either result is valid. Hence i suggest that test 84 and test 88
> (same failure) are special cased to "ext3" behaviour.

Done in the CVS.

> That means XFS is not failing any tests at all.

I added the xfs target but left the symlink Test 6 fail because POSIX says

 "The string pointed to by path1 shall be treated only as a character 
  string and shall not be validated as a pathname" 

and 
 
 "the length of the path1 argument is longer than {SYMLINK_MAX}" 

where {SYMLINK_MAX} is typically not defined on Linux or it's {PATH_MAX}.

	Szaka

--
NTFS-3G:  http://ntfs-3g.org

--
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