[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58235996-2da6-259c-a02c-9e7fcb499d62@nod.at>
Date: Mon, 24 Oct 2016 08:59:26 +0200
From: Richard Weinberger <richard@....at>
To: Eric Biggers <ebiggers@...gle.com>
Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, dedekind1@...il.com,
adrian.hunter@...el.com, tytso@....edu, jaegeuk@...nel.org,
david@...ma-star.at, wd@...x.de, sbabic@...x.de,
dengler@...utronix.de
Subject: Re: [PATCH 25/26] ubifs: Implement UBIFS_FLG_ENCRYPTION
Eric,
On 21.10.2016 20:30, Eric Biggers wrote:
> On Fri, Oct 21, 2016 at 02:48:40PM +0200, Richard Weinberger wrote:
>> @@ -190,6 +191,10 @@ long ubifs_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>> sizeof(policy)))
>> return -EFAULT;
>>
>> + err = ubifs_enable_encryption(c);
>> + if (err)
>> + return err;
>> +
>> err = fscrypt_process_policy(file, &policy);
>
> Is ubifs_enable_encryption() being done with proper locking and authorization?
Anyone can encrypted files when UBIFS is build with that feature. Locking is fine
since the operation is atomic. (UBI LEB change).
> As-is, anyone can call this at any time if they can open some file on UBIFS.
That's what I had in mind.
> FYI, the approach being taken for ext4 is that the encryption feature flag has
> to be explicitly turned on before FS_IOC_SET_ENCRYPTION_POLICY will work.
So, on ext4 (f2fs too?) root has to enable to feature first before users
can use it?
IOW for ext4 the encryption flag means "file encryption is allowed", for UBIFS it
means "at least one file got encrypted on this fs".
I think I'll do what ext4 does to have common policies.
BTW: Are these policies documented somewhere?
Thanks,
//richard
Powered by blists - more mailing lists