linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Anand Jain <anand.jain@oracle.com>,
	Eric Biggers <ebiggers3@gmail.com>,
	Eric Biggers <ebiggers@google.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Joe Richey <joerichey@google.com>
Subject: Re: fs/crypt ioctl and attr
Date: Tue, 7 Feb 2017 20:36:13 -0800	[thread overview]
Message-ID: <20170208043613.GF10498@birch.djwong.org> (raw)
In-Reply-To: <20170208024100.gp7nenim4fqf2kg5@thunk.org>

On Tue, Feb 07, 2017 at 09:41:00PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 07, 2017 at 05:52:15PM +0800, Anand Jain wrote:
> > 
> >  Sure. Hope I could confirm it here, that is - if its ok to entirely use
> >  setfattr / getfattr to read and write fs/crypto policy.
> 
> The controls on when it is legal to set a crypto policy on a file are
> different than for a normal extended attribute.  Furthermore, what is
> stored on disk is a combination of the fscrypt policy --- which is a
> fixed part of the userspace API --- and the some per-file
> cryptoggraphic nonces which are generated by the kernel, and which is
> subject to change in the future depending on the changes in the key
> derivation algorithm, the cipher used, etc.
> 
> For this reason using the standard xattr interface is **strongly**
> frowned upon.  Using setfattr / getfattr for something that *isn't*
> the standard user extended attribute has been a mess, and is
> considered a mistake that shouldn't be repeated.
> 
> This is why I chose to use a separate ioctl instead of trying to
> bastardize the setfattr / getfattr interface for something which is
> fundamentally *not* about setting an extended attribute.
> 
> There was discussion on linux-fsdevel a few months back where someone
> else wanted to perpetrate a similar abuse of the the set/get extended
> attribute interface, and other folks (I think it was Christoph and
> Dave Chinner) who argued very strongly that it wsa a bad, Bad, BAD,
> *BAD* idea.

As one of 'those people', I think I'm well qualified to say that a fake
xattr having side effects that doesn't behave in quite the same ways as
regular xattrs is setting up other programs (the ones that listxattr all
the attrs and getxattrs them) for all kinds of weird yuckiness.  And by
'weird yuckiness' I mean "this one magic xattr returned EOPNOTSUPP and
the whole backup program exploded".

Now granted you can argue that we're just shifting that into an ioctl,
but ioctls are already weird and yucky. :)

--D

> 
> Cheers,
> 
> 						- Ted

  reply	other threads:[~2017-02-08  4:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 23:19 fs/crypt ioctl and attr Anand Jain
2017-02-06 23:31 ` Eric Biggers
2017-02-07  5:55   ` Anand Jain
2017-02-07  7:34     ` Eric Biggers
2017-02-07  9:52       ` Anand Jain
2017-02-08  2:41         ` Theodore Ts'o
2017-02-08  4:36           ` Darrick J. Wong [this message]
2017-02-08 14:21             ` Theodore Ts'o
2017-02-08 18:55               ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170208043613.GF10498@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=anand.jain@oracle.com \
    --cc=ebiggers3@gmail.com \
    --cc=ebiggers@google.com \
    --cc=joerichey@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).