From: Richard Weinberger <richard@nod.at>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: overlayfs vs. fscrypt
Date: Wed, 13 Mar 2019 14:32:02 +0100 [thread overview]
Message-ID: <4066872.KGdO14EQMx@blindfold> (raw)
In-Reply-To: <CAJfpegtgfuAkgv26QH6Ht25OeMiev-QvEf7ror4KAbud7FADgg@mail.gmail.com>
Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > The use case is that you can delete these files if the DAC/MAC permissions allow it.
> > Just like on NTFS. If a user encrypts files, the admin cannot read them but can
> > remove them if the user is gone or loses the key.
>
> There's the underlying filesystem view where admin can delete files,
> etc. And there's the fscrypt layer stacked on top of the underlying
> fs, which en/decrypts files *in case the user has the key*. What if
> one user has a key, but the other one doesn't? Will d_revalidate
> constantly switch the set of dentries between the encrypted filenames
> and the decrypted ones? Sounds crazy. And the fact that NTFS does
> this doesn't make it any less crazy...
Well, I didn't come up with this feature. :-)
If one user has the key and the other not, a classic multi-user
system, then you need to make sure that the affected fscrypt instances
are not visible by both.
For example by using mount namespaces to make sure that user a can only
see /home/foo and user b only /home/bar.
Or removing the search permission on /home/foo and /home/bar.
I know, I know, but that's how it is...
Maybe Ted or Eric can give more details on why they chose this approach.
Thanks,
//richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: overlayfs vs. fscrypt
Date: Wed, 13 Mar 2019 14:32:02 +0100 [thread overview]
Message-ID: <4066872.KGdO14EQMx@blindfold> (raw)
In-Reply-To: <CAJfpegtgfuAkgv26QH6Ht25OeMiev-QvEf7ror4KAbud7FADgg@mail.gmail.com>
Am Mittwoch, 13. M�rz 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > The use case is that you can delete these files if the DAC/MAC permissions allow it.
> > Just like on NTFS. If a user encrypts files, the admin cannot read them but can
> > remove them if the user is gone or loses the key.
>
> There's the underlying filesystem view where admin can delete files,
> etc. And there's the fscrypt layer stacked on top of the underlying
> fs, which en/decrypts files *in case the user has the key*. What if
> one user has a key, but the other one doesn't? Will d_revalidate
> constantly switch the set of dentries between the encrypted filenames
> and the decrypted ones? Sounds crazy. And the fact that NTFS does
> this doesn't make it any less crazy...
Well, I didn't come up with this feature. :-)
If one user has the key and the other not, a classic multi-user
system, then you need to make sure that the affected fscrypt instances
are not visible by both.
For example by using mount namespaces to make sure that user a can only
see /home/foo and user b only /home/bar.
Or removing the search permission on /home/foo and /home/bar.
I know, I know, but that's how it is...
Maybe Ted or Eric can give more details on why they chose this approach.
Thanks,
//richard
next prev parent reply other threads:[~2019-03-13 13:32 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 12:31 overlayfs vs. fscrypt Richard Weinberger
2019-03-13 12:31 ` Richard Weinberger
2019-03-13 12:36 ` Miklos Szeredi
2019-03-13 12:47 ` Richard Weinberger
2019-03-13 12:47 ` Richard Weinberger
2019-03-13 12:58 ` Miklos Szeredi
2019-03-13 13:00 ` Richard Weinberger
2019-03-13 13:00 ` Richard Weinberger
2019-03-13 13:24 ` Miklos Szeredi
2019-03-13 13:32 ` Richard Weinberger [this message]
2019-03-13 13:32 ` Richard Weinberger
2019-03-13 14:26 ` Amir Goldstein
2019-03-13 15:16 ` Theodore Ts'o
2019-03-13 15:30 ` Richard Weinberger
2019-03-13 15:30 ` Richard Weinberger
2019-03-13 15:36 ` James Bottomley
2019-03-13 15:51 ` Eric Biggers
2019-03-13 16:13 ` James Bottomley
2019-03-13 16:24 ` Richard Weinberger
2019-03-13 16:44 ` Theodore Ts'o
2019-03-13 17:45 ` James Bottomley
2019-03-13 18:58 ` Theodore Ts'o
2019-03-13 19:17 ` James Bottomley
2019-03-13 19:57 ` Eric Biggers
2019-03-13 20:06 ` James Bottomley
2019-03-13 20:25 ` Eric Biggers
2019-03-13 21:04 ` James Bottomley
2019-03-13 22:13 ` Eric Biggers
2019-03-13 22:29 ` James Bottomley
2019-03-13 22:58 ` Eric Biggers
2019-03-13 16:06 ` Al Viro
2019-03-13 16:44 ` Eric Biggers
2019-03-13 19:19 ` Al Viro
2019-03-13 19:43 ` Eric Biggers
2019-03-13 15:30 ` Eric Biggers
2019-03-13 15:30 ` Eric Biggers
2019-03-13 20:33 ` Richard Weinberger
2019-03-13 20:33 ` Richard Weinberger
2019-03-13 22:26 ` Eric Biggers
2019-03-13 22:26 ` Eric Biggers
2019-03-13 22:42 ` Richard Weinberger
2019-03-14 7:34 ` Miklos Szeredi
2019-03-14 17:15 ` [RFC] fscrypt_key_required mount option Richard Weinberger
2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:15 ` [PATCH 1/4] fscrypt: Implement FS_CFLG_OWN_D_OPS Richard Weinberger
2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:15 ` [PATCH 2/4] fscrypt: Export fscrypt_d_ops Richard Weinberger
2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:15 ` [PATCH 3/4] ubifs: Simplify fscrypt_get_encryption_info() error handling Richard Weinberger
2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:15 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:49 ` Eric Biggers
2019-03-14 17:49 ` Eric Biggers
2019-03-14 20:54 ` Richard Weinberger
2019-03-14 20:54 ` Richard Weinberger
2019-03-14 23:07 ` Theodore Ts'o
2019-03-14 23:07 ` Theodore Ts'o
2019-03-15 0:26 ` Unsubscribe Shane Volpe
2019-03-15 7:48 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-15 7:48 ` Richard Weinberger
2019-03-15 13:51 ` Theodore Ts'o
2019-03-15 13:51 ` Theodore Ts'o
2019-03-15 13:51 ` Theodore Ts'o
2019-03-15 13:59 ` Richard Weinberger
2019-03-15 13:59 ` Richard Weinberger
2019-03-14 23:15 ` James Bottomley
2019-03-14 23:15 ` James Bottomley
2019-03-14 23:42 ` Theodore Ts'o
2019-03-14 23:42 ` Theodore Ts'o
2019-03-14 23:55 ` James Bottomley
2019-03-14 23:55 ` James Bottomley
2019-03-13 15:01 ` overlayfs vs. fscrypt Eric Biggers
2019-03-13 15:01 ` Eric Biggers
2019-03-13 16:11 ` Al Viro
2019-03-13 16:33 ` Eric Biggers
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=4066872.KGdO14EQMx@blindfold \
--to=richard@nod.at \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.