linux-kernel - Re: [PATCH 0/2] Fix two regressions from start_creating()/start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aVNHSjJVRGKjDBi0@elm>
Date: Mon, 29 Dec 2025 21:30:18 -0600
From: Tyler Hicks <code@...icks.com>
To: Amir Goldstein <amir73il@...il.com>,
	Dustin Kirkland <dustin.kirkland@...il.com>
Cc: NeilBrown <neil@...wn.name>, Christian Brauner <brauner@...nel.org>,
	Jeff Layton <jlayton@...nel.org>, ecryptfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Fix two regressions from
 start_creating()/start_removing() conversion

On 2025-12-27 19:15:18, Amir Goldstein wrote:
> On Sat, Dec 27, 2025 at 3:06 AM NeilBrown <neilb@...mail.net> wrote:
> >
> > On Wed, 24 Dec 2025, Tyler Hicks wrote:
> > > When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> > > from every test and that the umount utility was segfaulting when tearing
> > > down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> > > use new start_creating/start_removing APIs").
> > >
> > > This patch series addresses that regression and also a mknod problem
> > > spotted during code review.
> > >
> > > Tyler
> > >
> > > Tyler Hicks (2):
> > >   ecryptfs: Fix improper mknod pairing of
> > >     start_creating()/end_removing()
> > >   ecryptfs: Release lower parent dentry after creating dir
> > >
> > >  fs/ecryptfs/inode.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Thanks for finding and fixing these.
> > both
> >   Reviewed-by: NeilBrown <neil@...wn.name>
> >
> > I note that in https://lore.kernel.org/all/ZCuSLNnFQEdOHW0c@sequoia/ you
> > said of ecryptfs:
> >
> >     I'll send a patch to deprecate and mark for removal in 2025.
> >
> > Did it ever get marked for removal?  Is there a chance that it might be
> > removed?

I never did that, as I did hear from some folks that depend on it. Not a
lot of people but there were some.

> If it does get removed I wonder how I and other users would access my
> ecryptfs folders?

I have thought about stripping out the write abilities, after a warning
period, so that existing files could be read and migrated away but it
wouldn't grow new users.

> It sounds to me like the road to deprecation should go through creating
> a FUSE alternative in ecryptfs-utils, before the kernel driver is deprecated.
> 
> Tyler, are there any problems with doing that?
> I could give it a shot if I have your blessing.

That is a nice idea and I'd be happy if you did it! Do note that
ecryptfs-utils is even more stale than the kernel driver and hasn't seen
a release in a very long time. It is still stored in bzr instead of
git!

I'm not sure if Dustin Kirkland (cc'ed) has the bandwidth to make new
ecryptfs-utils releases to deliver a FUSE alternative but, if not, it
could be a good time to move to git and host new releases on GitHub or
maybe kernel.org.

Tyler

> 
> Thanks,
> Amir.