linux-kernel - [RFC] setxattr bugs

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

Message-ID: <20130203043046.GR4503@ZenIV.linux.org.uk>
Date:	Sun, 3 Feb 2013 04:30:46 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, Jeff Mahoney <jeffm@...e.com>,
	Dave Kleikamp <shaggy@...nel.org>
Subject: [RFC] setxattr bugs

	* JFS, since 2005: setxattr(name, "system.posix_acl_access", NULL, 0, 0)
succeeds, creating an empty EA with "system.posix_acl_access" as name.
Validity checks should apply _after_
        if (value == NULL) {    /* empty EA, do not remove */
                value = "";
                value_len = 0;
        }
and not before it.
	* reiserfs, since 2009: setxattr(name, attr_name, NULL, 0, 0) is
treated as removexattr(name, attr_name), not as emptying given xattr.

	The question is, does either of those cross into "established
weirdness in ABI" or are they still at the "bugs to be fixed" stage?

	FWIW, I'm seriously tempted to stop passing NULL as the
third argument of ->setxattr(), essentially taking all those
if (!value) value = ""; pieces from individual ->setxattr() instances
to __vfs_setxattr_noperm() (all other callers of ->setxattr() never
pass NULL data or 0 size, so it's irrelevant for them).  Would fix
both jfs and reiserfs weirdness....

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