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:	Mon, 1 Dec 2014 13:42:37 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	Richard Weinberger <richard@....at>, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org,
	"systemd-devel@...ts.freedesktop.org" 
	<systemd-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE

On Mon, 01.12.14 14:54, Dave Chinner (david@...morbit.com) wrote:

> On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> > On Mon, 01.12.14 01:41, Richard Weinberger (richard@....at) wrote:
> > 
> > > CC'ing systemd folks.
> > > 
> > > Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
> > > Maybe I'm reading the source horrible wrong.
> > 
> > For two usecases:
> > 
> > a) Being able to detect if something is a mount point. The traditional
> >    way to do this is by stat()ing the dir in question and its parent
> >    and comparing st_dev. That logic is not able to detect bind mounts
> >    however, if destination and the place the mount is at are actually
> >    on the same file system... Thus we check the mount id too, if we
> >    can get our hands on it.
> 
> So what you really want in the mount id in st_buf.st_dev, not the
> underlying device number. i.e. fstatat(dirfd, path, buf,
> AT_MOUNTID)?

Well, I am not a fan of overloading things, and there might be reasons
why one would want to know both the mount id and the device id at the
same time with one atomic call, but ultimately I don't really care,
and fstatat(AT_MOUNT_ID) would certainly be at least as useful as
name_to_handle_at() is. 

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