Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1631414
| Path | csiph.com!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!news.servidellagleba.it!bofh.it!news.nic.it!robomod |
|---|---|
| From | David Oberhollenzer <david.oberhollenzer@sigma-star.at> |
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing |
| Date | Wed, 26 Apr 2017 13:50:01 +0200 |
| Message-ID | <tAtCh-1In-13@gated-at.bofh.it> (permalink) |
| References | <tzU1Q-3Vb-19@gated-at.bofh.it> <tAcUO-7ME-13@gated-at.bofh.it> |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=windows-1252 |
| Content-Transfer-Encoding | 7bit |
| Sender | robomod@news.nic.it |
| List-ID | <linux-kernel.vger.kernel.org> |
| X-Mailing-List | linux-kernel@vger.kernel.org |
| Approved | robomod@news.nic.it |
| Lines | 22 |
| Organization | linux.* mail to news gateway |
| X-Original-Cc | linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fscrypt@vger.kernel.org, david@sigma-star.at |
| X-Original-Date | Wed, 26 Apr 2017 13:48:10 +0200 |
| X-Original-Message-ID | <1f759fee-337f-903a-0eb0-5b364cd35e6f@sigma-star.at> |
| X-Original-References | <1493070381-20075-1-git-send-email-richard@nod.at> <20170425175442.GB41477@google.com> |
| X-Original-Sender | linux-kernel-owner@vger.kernel.org |
| Xref | csiph.com linux.kernel:1631414 |
Show key headers only | View raw
On 04/25/2017 07:54 PM, Eric Biggers wrote:
> Did you test that this change actually does anything? Unlike ext4 and f2fs,
> ubifs calls fscrypt_setup_filename() from its rename methods rather than through
> a helper function ${FS}_find_entry(). Therefore it's able to pass in lookup=0,
> which means that the key is required. So it should already be failing with
> ENOKEY. You can verify this by running xfstests generic/419.
Actually, running xfstests was how this cropped up in the first place.
The UBIFS rename and xrename functions allready call
fscrypt_setup_filename with lookup=0, however there are other tests
before that call and moving them around causes generic/419 to fail
at a different place where EPERM was expected.
Therefore I concluded that the safest way to fix this might be to
simply copy the way the checks are handled in ext4.
With recent xfstests + UBIFS support patch, after applying this patch,
generic/419 passes.
David
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing Richard Weinberger <richard@nod.at> - 2017-04-24 23:50 +0200
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing Eric Biggers <ebiggers@google.com> - 2017-04-25 20:00 +0200
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing David Oberhollenzer <david.oberhollenzer@sigma-star.at> - 2017-04-26 13:50 +0200
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing Eric Biggers <ebiggers3@gmail.com> - 2017-04-27 01:00 +0200
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing David Oberhollenzer <david.oberhollenzer@sigma-star.at> - 2017-04-27 11:00 +0200
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing Eric Biggers <ebiggers3@gmail.com> - 2017-04-27 21:40 +0200
csiph-web