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]
Date:	Fri, 16 Dec 2011 23:30:42 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Sasha Levin <levinsasha928@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: Move attribute flags into non __KERNEL__ space

On Fri, Dec 16, 2011 at 11:30:40PM +0200, Sasha Levin wrote:
> On Fri, 2011-12-16 at 14:23 -0500, Christoph Hellwig wrote:
> > On Fri, Dec 16, 2011 at 09:47:06AM +0200, Sasha Levin wrote:
> > > Attribute flags can be useful in userspace when working with filesystems
> > > such as 9p.
> > 
> > No, they aren't.  They are kernel internal values and userspace has no
> > fucking business messing with them.
> > 
> 
> They became userspace business once they got exposed through 9p.
> 
> Take a look at <linux/net/9p/9p.h>:
> 
> 	/**
> 	 * struct p9_iattr_dotl - P9 inode attribute for setattr
> 	 * @valid: bitfield specifying which fields are valid
> 	 *         same as in struct iattr
> 	[...]
> 
> That structure is userspace facing, and it's using iattr values.
> 
> So either we expose them through fs.h, through 9p.h, or modify 9p code
> to not use them directly. But claiming that they're kernel internal
> values isn't entirely correct.

They *are* kernel internal values and 9P is asking for trouble exposing
them.  Translation: tomorrow we might reassign those as we bloody wish
and any userland code that happens to rely on their values will break.
At which point we'll handle complaints by pointing and laughing.

It's a 9P bug; fix it there.  Turning random internal constants into a part
of ABI is not going to work.
--
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