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]

Date:   Fri, 1 Feb 2019 07:43:01 +1100
From:   Dave Chinner <david@...morbit.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.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 09:40:59AM -0800, Darrick J. Wong wrote:
> 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?

It doesn't, and that is the problem here.

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

It already is - see include/linux/kprojid.h.

That was done for user namespaces, despite my objections that
project IDs aren't something that user namespaces should swizzle
because they are filesystem controlled IDs and the init namespace
needs to use them to control container directory space usage,
therefore they are not available for use in user namespaces
contexts.....

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

Makes no difference to me where they are stored - settattr has to
call into the filesystem anyway to change them (transactions!) so it
doesn't need to be in the struct inode, just in the struct iattr
that is passed to the filesystems.

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

Kinda what I was thinking, so we don't need a whole new syscall.
Just limit that flag usage to the init namespace and we're all good.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com