On Mon, 2020-09-14 at 18:37 -0700, Eric Biggers wrote:
> On Mon, Sep 14, 2020 at 03:17:01PM -0400, Jeff Layton wrote:
> > diff --git a/fs/ceph/crypto.h b/fs/ceph/crypto.h
> > index b5f38ee80553..c1b6ec4b2961 100644
> > --- a/fs/ceph/crypto.h
> > +++ b/fs/ceph/crypto.h
> > @@ -11,6 +11,8 @@
> > #define CEPH_XATTR_NAME_ENCRYPTION_CONTEXT "encryption.ctx"
> >
> > void ceph_fscrypt_set_ops(struct super_block *sb);
> > +int ceph_fscrypt_prepare_context(struct inode *dir, struct inode *inode,
> > + struct ceph_acl_sec_ctx *as);
> >
> > #else /* CONFIG_FS_ENCRYPTION */
> >
> > @@ -19,6 +21,12 @@ static inline int ceph_fscrypt_set_ops(struct super_block *sb)
> > return 0;
> > }
> >
> > +static inline int ceph_fscrypt_prepare_context(struct inode *dir, struct inode *inode,
> > + struct ceph_acl_sec_ctx *as)
> > +{
> > + return 0;
> > +}
> > +
> > #endif /* CONFIG_FS_ENCRYPTION */
>
> Seems there should at least be something that prevents you from creating a file
> in an encrypted directory when !CONFIG_FS_ENCRYPTION.
>
> The other filesystems use fscrypt_prepare_new_inode() for this; it returns
> EOPNOTSUPP when IS_ENCRYPTED(dir).
>
Once we have the MDS support done, we should be able to make it reject
create requests from clients that don't support the new feature flag,
but denying it on the client is more efficient. Fixed in my tree.
Thanks!
--
Jeff Layton <jlayton@xxxxxxxxxx>
