linux-kernel - Re: [PATCH] UBIFS: fill f

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: <1220376569.2982.225.camel@pmac.infradead.org>
Date:	Tue, 02 Sep 2008 18:29:29 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Andreas Dilger <adilger@....com>
Cc:	Artem Bityutskiy <dedekind@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Adrian Hunter <ext-adrian.hunter@...ia.com>
Subject: Re: [PATCH] UBIFS: fill f_fsid

On Tue, 2008-09-02 at 11:09 -0600, Andreas Dilger wrote:
> The fsid is supposed to be a persistent, unique identifier for the
> filesystem, used by NFS in file handles.  Using st_dev is unsafe,
> because that may change from one server boot to the next, because
> of device probing order, driver changes, etc.  Also, not all
> filesystems
> HAVE a valid st_dev in the first place, which is the whole reason
> for this thread.

Yes, putting st_dev in f_fsid probably isn't a good thing to do.

> I think a ->get_fsid() export method would be preferable.

I implemented that, but it doesn't really work. The fsid->export mapping
happens in userspace, so mountd needs access to the fsid. So the mount
would work fine and return a FH with the appropriate fsid, and then
mountd would have no knowledge of how to handle that FH, and mount(8) on
the client would eventually time out and fail.

It worked if I prepopulated the nfsd.fh cache in expkey_parse() so we
didn't end up asking userspace to resolve that FH for us -- but that was
just a quick hack. It wouldn't have worked after a server reboot, for
example -- we'd have asked userspace again.

We'd need to export that fsid to userspace somehow. I did briefly think
about adding something like ',uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' to
each line in /proc/mounts, as if it was a file system option -- but I
don't like that much.

When looking for other options, I realised that we already have the
f_fsid field in struct statfs, and we might as well just use that. That
does seem to be what it was _designed_ for, after all.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/