All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA
Date: Fri, 22 Jan 2016 07:57:19 -0600	[thread overview]
Message-ID: <56A2353F.4000400@sandeen.net> (raw)
In-Reply-To: <20160122085549.GB16898@quack.suse.cz>


On 1/22/16 2:55 AM, Jan Kara wrote:
> On Thu 21-01-16 22:07:19, Eric Sandeen wrote:
>> Q_XGETNEXTQUOTA is exactly like Q_XGETQUOTA, except that it
>> will return quota information for the id equal to or greater
>> than the id requested.  In other words, if the requested id has
>> no quota, the command will return quota information for the
>> next higher id which does have a quota set.  If no higher id
>> has an active quota, -ESRCH is returned.
>>
>> This allows filesystems to do efficient iteration in kernelspace,
>> much like extN filesystems do in userspace when asked to report
>> all active quotas.
>>
>> The patch adds a d_id field to struct qc_dqblk so that we can
>> pass back the id of the quota which was found, and return it
>> to userspace.
>>
>> Today, filesystems such as XFS require getpwent-style iterations,
>> and for systems which have i.e. LDAP backends, this can be very
>> slow, or even impossible if iteration is not allowed in the
>> configuration.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ...
>> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
>> index ea66670..4bf8d40 100644
>> --- a/fs/quota/quota.c
>> +++ b/fs/quota/quota.c
>> @@ -33,6 +33,7 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
>>  	/* allow to query information for dquots we "own" */
>>  	case Q_GETQUOTA:
>>  	case Q_XGETQUOTA:
>> +	case Q_XGETNEXTQUOTA:
> 
> IMO you should require CAP_SYS_ADMIN for the quotactl. Definitely doing the
> UID and GID checks for GETNEXTQUOTA looks strange to me since the returned
> structure may be for a different ID. Or did you assume that existing user
> will have quota structure allocated so we always return quotas for that ID
> in that case? I'm not sure this is good to rely on...

Oh whoops.  OK that was dumb of me, thanks for catching it.  No, I
didn't intend to rely on the asking user having a quota, it was
just a dumb mistake.  :)

>> +	ret = sb->s_qcop->get_nextdqblk(sb, qid, &qdq);
>> +	if (ret)
>> +	        return ret;
>> +	copy_to_xfs_dqblk(&fdq, &qdq, type, qdq.d_id);
>> +	if (copy_to_user(addr, &fdq, sizeof(fdq)))
>> +	        return -EFAULT;
>> +	return ret;
>> +}
> 
> So how about passing pointer to 'qid' to ->get_nextdqblk() and return the ID
> that way? That will also force you to fix the issue that you currently
> completely miss user-namespace conversions for the ID ;).

Ok.

> I definitely dislike mixing d_id in the qdq structure with arguments of fs
> callbacks and that d_id doesn't get filled for most callbacks. That is going
> to cause confusion.

Yeah, fair enough.  I'll change it.

Thanks,
-Eric

> 								Honza
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@sandeen.net>
To: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA
Date: Fri, 22 Jan 2016 07:57:19 -0600	[thread overview]
Message-ID: <56A2353F.4000400@sandeen.net> (raw)
In-Reply-To: <20160122085549.GB16898@quack.suse.cz>


On 1/22/16 2:55 AM, Jan Kara wrote:
> On Thu 21-01-16 22:07:19, Eric Sandeen wrote:
>> Q_XGETNEXTQUOTA is exactly like Q_XGETQUOTA, except that it
>> will return quota information for the id equal to or greater
>> than the id requested.  In other words, if the requested id has
>> no quota, the command will return quota information for the
>> next higher id which does have a quota set.  If no higher id
>> has an active quota, -ESRCH is returned.
>>
>> This allows filesystems to do efficient iteration in kernelspace,
>> much like extN filesystems do in userspace when asked to report
>> all active quotas.
>>
>> The patch adds a d_id field to struct qc_dqblk so that we can
>> pass back the id of the quota which was found, and return it
>> to userspace.
>>
>> Today, filesystems such as XFS require getpwent-style iterations,
>> and for systems which have i.e. LDAP backends, this can be very
>> slow, or even impossible if iteration is not allowed in the
>> configuration.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ...
>> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
>> index ea66670..4bf8d40 100644
>> --- a/fs/quota/quota.c
>> +++ b/fs/quota/quota.c
>> @@ -33,6 +33,7 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
>>  	/* allow to query information for dquots we "own" */
>>  	case Q_GETQUOTA:
>>  	case Q_XGETQUOTA:
>> +	case Q_XGETNEXTQUOTA:
> 
> IMO you should require CAP_SYS_ADMIN for the quotactl. Definitely doing the
> UID and GID checks for GETNEXTQUOTA looks strange to me since the returned
> structure may be for a different ID. Or did you assume that existing user
> will have quota structure allocated so we always return quotas for that ID
> in that case? I'm not sure this is good to rely on...

Oh whoops.  OK that was dumb of me, thanks for catching it.  No, I
didn't intend to rely on the asking user having a quota, it was
just a dumb mistake.  :)

>> +	ret = sb->s_qcop->get_nextdqblk(sb, qid, &qdq);
>> +	if (ret)
>> +	        return ret;
>> +	copy_to_xfs_dqblk(&fdq, &qdq, type, qdq.d_id);
>> +	if (copy_to_user(addr, &fdq, sizeof(fdq)))
>> +	        return -EFAULT;
>> +	return ret;
>> +}
> 
> So how about passing pointer to 'qid' to ->get_nextdqblk() and return the ID
> that way? That will also force you to fix the issue that you currently
> completely miss user-namespace conversions for the ID ;).

Ok.

> I definitely dislike mixing d_id in the qdq structure with arguments of fs
> callbacks and that d_id doesn't get filled for most callbacks. That is going
> to cause confusion.

Yeah, fair enough.  I'll change it.

Thanks,
-Eric

> 								Honza
> 

  reply	other threads:[~2016-01-22 13:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22  4:07 [PATCH 0/7 V2] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22  4:07 ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 1/7] quota: remove unused cmd argument from quota_quotaon() Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  8:55   ` Jan Kara
2016-01-22  8:55     ` Jan Kara
2016-01-22 13:57     ` Eric Sandeen [this message]
2016-01-22 13:57       ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 3/7] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  9:28   ` Jan Kara
2016-01-22  9:28     ` Jan Kara
2016-01-22 13:58     ` Eric Sandeen
2016-01-22 13:58       ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 4/7] xfs: don't overflow quota ID when initializing dqblk Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 5/7] xfs: get quota inode from mp & flags rather than dqp Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 6/7] xfs: Factor xfs_seek_hole_data into helper Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 7/7] xfs: wire up Q_XGETNEXTQUOTA / get_nextdqblk Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2016-01-22 18:25 [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-25 14:51   ` Jan Kara
2016-01-25 14:51     ` Jan Kara
2016-01-26 12:57   ` Jan Kara
2016-01-26 12:57     ` Jan Kara
2016-01-26 15:00     ` Eric Sandeen
2016-01-26 15:00       ` Eric Sandeen
2016-01-26 17:52       ` Jan Kara
2016-01-26 17:52         ` Jan Kara
2016-01-26 17:57         ` Eric Sandeen
2016-01-26 17:57           ` Eric Sandeen
2016-01-26 18:39         ` Eric Sandeen
2016-01-26 18:39           ` Eric Sandeen
2016-01-26 20:40           ` Jan Kara
2016-01-26 20:40             ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A2353F.4000400@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.