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

On Tue, 2008-09-02 at 17:48 -0400, Christoph Hellwig wrote:
> On Tue, Sep 02, 2008 at 10:26:09PM +0100, David Woodhouse wrote:
> > > We also called the filesystem part of the NFS filehandle in a few
> > > places, and for those it's correct that it should be stable.  Currently
> > > the fsid is either created from the dev_t in kernelspace or from
> > > uuids extracted through libuuid in userspace.
> > 
> > Or from the f_fsid returned in statfs(), as of a week or so ago.
> 
> I think that's a rather bad idea.  As mentioned before f_fsid is
> basically random.

It's not that bad. Of the file systems which actually fill it in...

For NTFS it's the volume serial number.

For ext[234] it's the UUID xor-folded into 64 bits.
For btrfs the same, but with the root object ID xor'd in too.

For bfs and xfs it's the block device -- which isn't ideal, as Andreas
points out, but is what we'd fall back to anyway.

BFS seems to have a s_volume field which perhaps we could use, but we
should check for it being all spaces and leave f_fsid as zero in that
case. Presumably XFS could be using sb_uuid?

For efs, it'll be either EFS_MAGIC or EFS_NEWMAGIC, which is probably a
bad thing if you want to export multiple EFS file systems. I'll send a
patch to fix that (by leaving it zero) shortly.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ