linux-kernel - Re: [PATCH] xattr: Fix error results for non-existent / invisible attributes

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

Message-ID: <1308620057.2983.17.camel@schurl.linbit>
Date:	Tue, 21 Jun 2011 03:34:17 +0200
From:	Andreas Gruenbacher <agruen@...nel.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] xattr: Fix error results for non-existent / invisible
 attributes

On Mon, 2011-06-20 at 04:09 -0400, Christoph Hellwig wrote:
> On Fri, May 27, 2011 at 02:50:36PM +0200, Andreas Gruenbacher wrote:
> > Return -ENODATA when trying to read a user.* attribute which cannot
> > exist: user space otherwise does not have a reasonable way to
> > distinguish between non-existent and inaccessible attributes.
> > 
> > Likewise, return -ENODATA when an unprivileged process tries to read a
> > trusted.* attribute: to unprivileged processes, those attributes are
> > invisible (listxattr() won't include them).
> 
> This breaks xfstests 062.

The test does a "getfattr -n <name> <file>" for an attribute which
cannot exist.  The kernel now returns ENODATA instead of the previous
EPERM.

One way to fix this in xfstests is to use listxattr(2) instead of
getxattr(2), e.g.,

	- getfattr -m $nsp -n $nsp.name2 $SCRATCH_MNT/$inode
	+ getfattr -m $nsp.name2 $SCRATCH_MNT/$inode

Another is to accept ENODATA as well as EPERM.  Not sure which is preferable.

Andreas

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