linux-ext4 - Re: [RFC][PATCH 7/9]ext4: Add the EXT4_IOC_FIEMAP

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:	Fri, 31 Oct 2008 18:46:12 +0900
From:	Akira Fujita <a-fujita@...jp.nec.com>
To:	Andreas Dilger <adilger@....com>
CC:	linux-ext4@...r.kernel.org, Theodore Tso <tytso@....edu>,
	Mingming Cao <cmm@...ibm.com>, hch@...radead.org
Subject: Re: [RFC][PATCH 7/9]ext4: Add the EXT4_IOC_FIEMAP_INO ioctl


Andreas Dilger Wrote:
> On Oct 27, 2008  19:21 +0900, Akira Fujita wrote:
>> Andreas Dilger wrote:
>>> On Oct 24, 2008  19:09 +0900, Akira Fujita wrote:
>>>> The EXT4_IOC_FIEMAP_INO is used to get extents information of
>>>> inode which set to ioctl.
>>>> The defragger uses this ioctl to check the fragment condition
>>>> and to get extents information in the specified block group.
>>> Instead of having a separate IOC number for each such ioctl, instead
>>> we implemented EXT4_IOC_WRAPPER, which is an root-specific ioctl that
>>> passes in an inode number and a second IOC number so that arbitrary file
>>> ioctls can be run on any inode by root.
>> The EXT4_IOC_WRAPPER ioctl seems to be usuful for many situations.
>> But the EXT4_IOC_FIEMAP_INO ioctl is used not only root user but also
>> non-root user to call fiemap,
>> so we cannot use the current EXT4_IOC_WRAPPER ioctl for defrag.
> 
> Why does a regular user need to do the ioctl on a file that it may not
> have read permission to access?  I can see this is useful for root
> doing a defrag of the whole filesystem instead of opening and closing
> all of the files, but for regular users we need to validate via the
> full path to ensure they can even access the file before defragmenting it.

The FIEMAP_INO ioctl just passes a inode number belongs to
the target block group from user space to kernel space
and then the owner check is done in the kernel space.
If the regular user (defrag -f excecutant) is owner of a file,
defrag handles this file as the candidate of victim file which would be moved
to the other block group to make free space.

So I think the full path check is unneeded because the owner check
is done in the kernel space (I'm not sure it's good enough).
If it's not good in the security point of view,
I will make defrag -f mode be done only by root user.

>>> This was mentioned last time these patches were posted, but there was
>>> no reply from you.  Christoph suggested a more generic VFS open-by-inum,
>>> which isn't impossible to do but would cause a lot of controversy I
>>> think, while the EXT4_IOC_WRAPPER is at least contained within ext4,
>>> but is more generically useful than EXT4_IOC_FIEMAP_INO.
>> Do you plan to add EXT4_IOC_WRAPPER into the ext4 patch queue?
> 
> If there is interest, yes.

How do the other ext4 developers think about
implementing EXT4_IOC_WRAPPER?
Will it be used only for defrag so far?

Regards,
Akira Fujita
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html