Linux-Fsdevel Archive on
 help / color / Atom feed
From: "Theodore Y. Ts'o" <>
To: Andreas Dilger <>
Cc: "Darrick J. Wong" <>,
	Wang Shilong <>,,,
	Ext4 Developers List <>,
	Li Xi <>, Wang Shilong <>
Subject: Re: [Project Quota]file owner could change its project ID?
Date: Sun, 20 Oct 2019 18:25:29 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Oct 20, 2019 at 02:19:19PM -0600, Andreas Dilger wrote:
> > We could also solve the problem by adding an LSM hook called when
> > there is an attempt to set the project ID, and for people who really
> > want this, they can create a stackable LSM which enforces whatever
> > behavior they want.
> So, rather than add a few-line change that decides whether the user
> is allowed to change the projid for a file, we would instead add *more*
> lines to add a hook, then have to write and load an LSM that is called
> each time?  That seems backward to me.

I'm just not sure we've necessarily gotten the semantics right.  For
example, I could easily see someone else coming out of the woodwork
saying that The Right Model (tm) is one where users belong to a number
of projects (much like supplementary group ID's) and you should be
able to set the project of any file that you own to a project.

Or perhaps the policy is that you can only change the project ID if
the project ID has a non-zero project quota.  etc.

> > If we think this going to be an speciality request, this might be the
> > better way to go.
> I don't see how this is more "speciality" than regular quota enforcement?
> Just like we impose limits on users and groups, it makes sense to impose
> a limit on a project, instead of just tracking it and then having to add
> extra machinery to impose the limit externally.

We *do* have regular quota enforcement.  The question here has nothing
to do with how quota tracking or enforcement work.  The question is
about what are the authorization checks and policy surrounding when
the project ID can modified.

Right now the policy is "the owner of the file can set the project ID
to any integer if it is issued from the initial user namespace;
otherwise, no changes to the project ID or the PROJINHERIT flag is

Making it be "only root in the inital user namespace is allowed change
project ID or PROJINHERIT flag" is certain an alternate policy.  Are
we sure those are the only two possible policies that users might ask

					- Ted

  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-12  6:33 Wang Shilong
2019-10-12 20:51 ` Dave Chinner
2019-10-13 16:41 ` Darrick J. Wong
2019-10-16 11:51   ` Wang Shilong
2019-10-16 21:22     ` Dave Chinner
2019-10-16 21:37     ` Darrick J. Wong
2019-10-17  0:28       ` Andreas Dilger
2019-10-17 12:12         ` Theodore Y. Ts'o
2019-10-20 20:19           ` Andreas Dilger
2019-10-20 22:25             ` Theodore Y. Ts'o [this message]
2019-10-21 21:15               ` Andreas Dilger
2019-10-21 23:35         ` Dave Chinner
2019-10-23 23:01           ` Andreas Dilger

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Fsdevel Archive on

Archives are clonable:
	git clone --mirror linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ \
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone