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: Thu, 22 Feb 2024 17:08:23 +0100
From: Jan Kara <jack@...e.cz>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Jan Kara <jack@...e.cz>, Kent Overstreet <kent.overstreet@...ux.dev>,
	Josef Bacik <josef@...icpanda.com>, linux-kernel@...r.kernel.org,
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	lsf-pc@...ts.linux-foundation.org, linux-btrfs@...r.kernel.org
Subject: Re: [Lsf-pc] [LSF TOPIC] statx extensions for subvol/snapshot
 filesystems & more

On Thu 22-02-24 13:48:45, Miklos Szeredi wrote:
> On Thu, 22 Feb 2024 at 12:01, Jan Kara <jack@...e.cz> wrote:
> 
> > I think for "unique inode identifier" we don't even have to come up with
> > new APIs. The file handle + fsid pair is an established way to do this,
> 
> Why not uuid?
> 
> fsid seems to be just a degraded uuid.   We can do better with statx
> and/or statmount.

fanotify uses fsid because we have standard interface for querying fsid
(statfs(2)) and because not all filesystems (in particular virtual ones)
bother with uuid. At least the first thing is being changed now.

> > fanotify successfully uses this as object identifier and Amir did quite
> > some work for this to be usable for vast majority of filesystems (including
> 
> Vast majority != all.

True. If we are going to use this scheme more widely, we need to have a
look whether the remaining cases need fixing or we can just ignore them.
They were not very interesting for fanotify so we moved on.

> Also even uuid is just a statistically unique
> identifier, while st_dev was guaranteed to be unique (but not
> persistent, like uuid).

Well, everything is just statistically true in this world :) If you have
conflicting uuids, you are likely to see also other problems so I would not
be too concerned about that.

> If we are going to start fixing userspace, then we better make sure to
> use the right interfaces, that won't have issues in the future.

I agree we should give this a good thought which identification of a
filesystem is the best.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ