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] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f267de72403a3d6fb84a5d41ebf574128eb334d.camel@kernel.org>
Date: Wed, 13 Nov 2024 08:29:10 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Erin Shepherd <erin.shepherd@....eu>, "Darrick J. Wong"
 <djwong@...nel.org>
Cc: Christian Brauner <brauner@...nel.org>, Amir Goldstein
 <amir73il@...il.com>,  linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org,  christian@...uner.io, paul@...l-moore.com,
 bluca@...ian.org, Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [PATCH 0/4] pidfs: implement file handle support

On Wed, 2024-11-13 at 11:17 +0100, Erin Shepherd wrote:
> On 13/11/2024 01:40, Darrick J. Wong wrote:
> > > Hmm, I guess I might have made that possible, though I'm certainly not
> > > familiar enough with the internals of nfsd to be able to test if I've done
> > > so.
> > AFAIK check_export() in fs/nfsd/export.c spells this it out:
> > 
> > 	/* There are two requirements on a filesystem to be exportable.
> > 	 * 1:  We must be able to identify the filesystem from a number.
> > 	 *       either a device number (so FS_REQUIRES_DEV needed)
> > 	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> > 	 * 2:  We must be able to find an inode from a filehandle.
> > 	 *       This means that s_export_op must be set.
> > 	 * 3: We must not currently be on an idmapped mount.
> > 	 */
> > 
> > Granted I've been wrong on account of stale docs before. :$
> > 
> > Though it would be kinda funny if you *could* mess with another
> > machine's processes over NFS.
> > 
> > --D
> 
> To be clear I'm not familiar enough with the workings of nfsd to tell if
> pidfs fails those requirements and therefore wouldn't become exportable as
> a result of this patch, though I gather from you're message that we're in the
> clear?
> 
> Regardless I think my question is: do we think either those requirements could
> change in the future, or the properties of pidfs could change in the future,
> in ways that could accidentally make the filesystem exportable?
> 
> I guess though that the same concern would apply to cgroupfs and it hasn't posed
> an issue so far.

We have other filesystems that do this sort of thing (like cgroupfs),
and we don't allow them to be exportable. We'll need to make sure that
that's the case before we merge this, of course, as I forget the
details of how that works.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ