Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <e7f91d0be0f41320e5a4f38ded1bde166626a17f.camel@kernel.org>
Subject: Re: [PATCH 0/3] ceph: minor fixes and encrypted snapshot names
From:   Jeff Layton <jlayton@kernel.org>
To:     =?ISO-8859-1?Q?Lu=EDs?= Henriques <lhenriques@suse.de>
Cc:     Xiubo Li <xiubli@redhat.com>, Ilya Dryomov <idryomov@gmail.com>,
        ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Fri, 04 Mar 2022 13:30:50 -0500
In-Reply-To: <87fsnx4rb3.fsf@brahms.olymp>
References: <20220304161403.19295-1-lhenriques@suse.de>
         <87fsnx4rb3.fsf@brahms.olymp>
Content-Type: text/plain; charset="ISO-8859-15"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Fri, 2022-03-04 at 16:26 +0000, Lu?s Henriques wrote:
> Lu?s Henriques <lhenriques@suse.de> writes:
> 
> > Hi!
> > 
> > I'm sending another iteration of the encrypted snapshot names patch.  This
> > patch assumes PR#45224 [1] to be merged as it adds support for the
> > alternate names.
> > 
> > Two notes:
> > 
> > 1. Patch 0001 is just a small fix from another fscrypt patch.  It's
> >    probably better to simply squash it.
> > 
> > 2. I'm not sure how easy it is to hit the UAF fixed by patch 0002.  I can
> >    reproduce it easily by commenting the code that adds the
> >    DCACHE_NOKEY_NAME flag in patch 0003.
> 
> Obviously, immediately after sending this patchset I realized I failed to
> mention a very (*VERY*) important note:
> 
> Snapshot names can not start with a '_'.  I think the reason is related
> with the 'long snapshot names', but I can't really remember the details
> anymore.  The point is that an encrypted snapshot name base64-encoded
> *may* end-up starting with an '_' as we're using the base64-url variant.
> 
> I really don't know if it's possible to fix that.  I guess that in that
> case the user will get an error and fail to create the snapshot but he'll
> be clueless because the reason.  Probably a warning can be added to the
> kernel logs, but maybe there are other ideas.
> 


Ouch. Is that imposed by the MDS? It'd be best if we could remove that
limitation from it altogether if we can.

If we can't, then we might be able to get away with prepending all the
encrypted names with some legal characte. Then when we go to decrypt it
we just strip that off.

We could also consider changing the base64 routine to use something else
in lieu of '_' but that's more of a hassle.
-- 
Jeff Layton <jlayton@kernel.org>