linux-ext4 - Re: [RFC PATCH] ext4: add link file support for {GET,SET}XATTR ioctl

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]

Message-ID: <20190131174059.GA10211@magnolia>
Date:   Thu, 31 Jan 2019 09:40:59 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Dave Chinner <david@...morbit.com>
Cc:     Wang Shilong <wangshilong1991@...il.com>,
        linux-ext4@...r.kernel.org, linux-fs@...r.kernel.org,
        linux-xfs@...r.kernel.org, Wang Shilong <wshilong@....com>,
        Andreas Dilger <adilger@...ger.ca>, Li Xi <lixi@....com>
Subject: Re: [RFC PATCH] ext4: add link file support for {GET,SET}XATTR ioctl

On Thu, Jan 31, 2019 at 02:41:06PM +1100, Dave Chinner wrote:
> On Thu, Jan 31, 2019 at 10:47:12AM +0900, Wang Shilong wrote:
> > From: Wang Shilong <wshilong@....com>
> > 
> > Currently there is no way to change project ID of
> > symlink file itself, this is important to implement
> > Directory quota for an existed directory.
> 
> This seems like something open(O_PATH|O_NOFOLLOW) should allow.
> from open(2):

...but I thought O_PATH|O_NOFOLLOW file descriptions didn't allow ioctl
calls?

$ ln -sf urk /mnt/cow
$ xfs_io -c 'open -PL /mnt/cow' -c 'chproj 6'
setprojid: Bad file descriptor
$ ls -la /mnt/
lrwxrwxrwx 1 root root 3 Jan 31 09:30 /mnt/cow -> moo

> 	If pathname is a symbolic link and the O_NOFOLLOW flag is
> 	also specified, then the call returns a file  descriptor
> 	referring  to  the symbolic  link.  This  file  descriptor
> 	can  be used as the dirfd argument in calls to fchownat(2),
> 	fstatat(2), linkat(2), and read¿ linkat(2) with an empty
> 	pathname to have the calls operate on the symbolic link.
> 
> Changing the project id is the equivalent of fchownat().....

/me & others wonder (on the ext4 call) if maybe we should promote
project id to a vfs level concept?  i.e. store project id in struct
inode instead of the fs-specific inode structures.  Then we can use the
existing setattr infrastructure to persist those changes.

As for fchownat, how about a new flag that means "use the value in the
gid field to set the project id"?

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@...morbit.com