Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1503660 > unrolled thread

[RFD] Common userspace tool for fscypto

Back to article view | Back to linux.kernel

Contents

  [RFD] Common userspace tool for fscypto Richard Weinberger <richard@nod.at> - 2016-10-19 16:30 +0200
    Re: [RFD] Common userspace tool for fscypto Michael Halcrow <mhalcrow@google.com> - 2016-10-19 19:40 +0200
      Re: [RFD] Common userspace tool for fscypto Richard Weinberger <richard@nod.at> - 2016-10-24 14:10 +0200
    Re: [RFD] Common userspace tool for fscypto Karel Zak <kzak@redhat.com> - 2016-10-24 14:50 +0200
      Re: [RFD] Common userspace tool for fscypto Theodore Ts'o <tytso@mit.edu> - 2016-10-24 15:30 +0200

#1503660 — [RFD] Common userspace tool for fscypto

Hi!

Since file level encryption has more than one user, currently ext4, f2fs and soon ubifs
it would be nice to have a single tool to control fscrypto from userspace.

For ext4 we have already at least two tools, one as part of e2fsprogs and another
one on github[0]. IMHO the latter one is much more user friendly and intuitive to use.
I as unable to find the userspace tool for f2fs.

That said, what about implementing such a tool as part of util-linux to control
fscrypto? We (David and I) would volunteer.

Thanks,
//richard

[0] https://github.com/gdelugre/ext4-crypt

[toc] | [next] | [standalone]

#1504171

On Wed, Oct 19, 2016 at 4:35 AM, Richard Weinberger <richard@nod.at> wrote:
> Hi!
>
> Since file level encryption has more than one user, currently ext4, f2fs and soon ubifs
> it would be nice to have a single tool to control fscrypto from userspace.
>
> For ext4 we have already at least two tools, one as part of e2fsprogs and another
> one on github[0]. IMHO the latter one is much more user friendly and intuitive to use.
> I as unable to find the userspace tool for f2fs.
>
> That said, what about implementing such a tool as part of util-linux to control
> fscrypto? We (David and I) would volunteer.

While discussing several changes we have staged for release (we're
trying to minimize churn by batching a large set of format changes all
at once), we've recently recognized this need on my team and were
planning on starting work on exactly what you propose.

> Thanks,
> //richard
>
> [0] https://github.com/gdelugre/ext4-crypt

[toc] | [prev] | [next] | [standalone]

#1507129

Michael,

On 19.10.2016 19:36, Michael Halcrow wrote:
> On Wed, Oct 19, 2016 at 4:35 AM, Richard Weinberger <richard@nod.at> wrote:
>> Hi!
>>
>> Since file level encryption has more than one user, currently ext4, f2fs and soon ubifs
>> it would be nice to have a single tool to control fscrypto from userspace.
>>
>> For ext4 we have already at least two tools, one as part of e2fsprogs and another
>> one on github[0]. IMHO the latter one is much more user friendly and intuitive to use.
>> I as unable to find the userspace tool for f2fs.
>>
>> That said, what about implementing such a tool as part of util-linux to control
>> fscrypto? We (David and I) would volunteer.
> 
> While discussing several changes we have staged for release (we're
> trying to minimize churn by batching a large set of format changes all
> at once), we've recently recognized this need on my team and were
> planning on starting work on exactly what you propose.

Can you please some details?
Will it be GPL? Part of util-linux?
What features does it have?
I hope more than just being a wrapper to the ioctls().

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1507170

On Wed, Oct 19, 2016 at 01:35:54PM +0200, Richard Weinberger wrote:
> Hi!
> 
> Since file level encryption has more than one user, currently ext4, f2fs and soon ubifs
> it would be nice to have a single tool to control fscrypto from userspace.
> 
> For ext4 we have already at least two tools, one as part of e2fsprogs and another
> one on github[0]. IMHO the latter one is much more user friendly and intuitive to use.
> I as unable to find the userspace tool for f2fs.
> 
> That said, what about implementing such a tool as part of util-linux to control
> fscrypto? We (David and I) would volunteer.

I have nothing against this plan (add to util-linux) if ext4, f2fs and
ubifs guys agree too.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[toc] | [prev] | [next] | [standalone]

#1507205

On Mon, Oct 24, 2016 at 02:49:37PM +0200, Karel Zak wrote:
> > That said, what about implementing such a tool as part of util-linux to control
> > fscrypto? We (David and I) would volunteer.
> 
> I have nothing against this plan (add to util-linux) if ext4, f2fs and
> ubifs guys agree too.

Our current plan is to implement it in e2fsprogs since we can more
quickly iterate over code reviews and code improvements.  At some
future point I'm happy to transfer it over to util-linux much like
we've done with blkid and uuid libraries and associated utilities.
We'll probably also keep a version in e2fsprogs for the long term just
because upstream e2fsprogs is now integrated into the Android's AOSP
build infrastructure, and it's probably simpler keep the tool there
than to try to add Android.mk files and add the necessary helper
scripts to deal with the fact (a) in the AOSP build system, you have
to be able to cross-compile packages using Linux, MacOS, and Windows
as the host OS and (b) Android using the Bionic C library instead of
glibc.


In answer to Richard's other questions, of course it would be released
under the GPL, and our goals for creating a new fscrypto are (a) make
it be more user-friendly, (b) support the new file-system level
encryption features and new algorithms which Michael's team will be
implementing, including a stronger string-to-key (password hashing)
algorithm, new encryption modes, data integrity, etc), and (c) not
have to be tied to backwards compatibility concerns with the e4crypt
command.  (Since we are just starting a new e2fsprogs 1.44 development
cycle, we'll have plenty of time to experiment with the UI and make
incompatible changes before 1.44 gets released and at that point I
would want to lock down the any option names, etc., for long-term
backwards compatibility.)

I suspect we'll keep e4crypt around for a while, just because it's a
handy debugging tool, and in general it's faster to add quick wrapper
around ioctls for testing purposes than it is to be very thoughtful
about creating a UI which is both friendly and able to support new
features in a backwards compatible way.

I also suspect we'll want to put most of the bits that could be
usefully called from other C programs (e.g., Android's userspace
stack, and libpam modules) and put it in a new libfscrypto library.

Cheers,

						- Ted

P.S.  If anyone is ever interested in trying to make util-linux build
using AOSP (which would be cool since every once in a while I wish I
had some of the util-linux tools purely for debugging purposes, but
it's a bunch of work and I've never had the time, plus I wasn't at all
convinced Karel would be willing to accept such changes upstream for
util-linux), see e2fsprogs's Android.mk files plus the script in
util/gen-android-files.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web