linux-kernel - Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name

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

Message-ID: <856298.92497.qm@web36605.mail.mud.yahoo.com>
Date:	Fri, 29 Feb 2008 09:46:14 -0800 (PST)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Trond Myklebust <trond.myklebust@....uio.no>,
	casey@...aufler-ca.com
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Quigley <dpquigl@...ho.nsa.gov>,
	Stephen Smalley <sds@...ho.nsa.gov>, viro@....linux.org.uk,
	bfields@...ldses.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name

--- Trond Myklebust <trond.myklebust@....uio.no> wrote:

> 
> On Thu, 2008-02-28 at 17:55 -0800, Casey Schaufler wrote:
> 
> > > There should be no need for ioctls.
> > 
> > Sorry, but as far as I'm concerned you just threw a bunny under
> > the train for no apparent reason. What have ioctls got to do with
> > anything?
> 
> What part of 'interoperability' don't you get here?

I can understand that an implementation of NFS+xattr could
present some issues where only one side speaks the xattr
protocols, or where they speak them differently. If that's
a showstopper from the network protocol side (it isn't from
the file system end, client or server) then you're right,
it won't work. What I don't understand is why it would be
a showstopper. The current NFS protocol makes all sorts of
assumptions about the data it passes (like the uids on the
two ends mapping sanely) that seem to me to be as much a
problem as xattr value mapping.

> There is no room for extensions that allow clients+servers to establish
> arbitrary private protocols.

I think that I understand that you believe that, what I
don't understand is why you believe that. Is it an artifact
of the locking protocol that only worked about half the
time, and then in a half donkied way?

I'm not trying to be an obstructionist idiot here, even if
that's how it may appear. I have my pet solution, I really
don't see the problem with it, and it looks to me like the
arguements against it are either so obvious I'm missing them
(does happen) or based on dogmas I don't subscribe to.

Thank you for helping me (and maybe some others) understand
the issues we're up against so that I (we) can address issues
better in the future.

Casey Schaufler
casey@...aufler-ca.com
--
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/