linux-kernel - Re: [PATCH] x86: defconfig: Enable CONFIG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Dec 2014 02:03:43 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Richard Weinberger <richard@....at>
Cc:	Dave Chinner <david@...morbit.com>, 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 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. This actually fixes real-life
   problems. For example time-based recursive clean-up logic in /tmp,
   where it is desirable that the clean up stops at
   submounts. However, we had reports where the clean-up fucked up
   people's home directories because they mounted them for some reason
   into some subdir in /tmp and they had /tmp and /home on the same
   fs.

b) Because we sometimes want to know the mount options used for
   specific file systems. For that you want to correlate
   /proc/self/mountinfo with a path in the fs. You can of course try
   to do path prefix matching and then fuck things up as soon as
   people do weird mounts on top of each other. Or you can use use the
   mount id name_to_handle tells you and look it up in
   /proc/self/mountinfo, and everything is clean and reliable.

We have no interest in the actual fhandle data. If you give us some
other syscall to figure out the mount id, we'd be delighted to use it
instead.

udev uses the logic described in b) to determine if /dev is a devtmpfs
instance. Since devtmpfs has the same fs magic as any other tmpfs we
cannot use the statfs() magic stuff to detect this case.

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/