On Oct 20, 2019, at 4:25 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > 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. Definitely I've thought of that kind of behavior, but it needs a much larger change, and is not clear that anyone actually needs this yet. It is not incompatible with the "add an option for root-only (or specific GID-only) 'setprojid' permission", but rather would be an enhancement that could be added after the fact (there is no need for it with the "free for all" today). However, I'm uncertain whether any benefit would be had from "supplementary projid" support as you describe or not. If a user has write permission in a target directory with a different projid then they can easily (with "mv" handling the EXDEV case automatically) move files from a source projid to a target projid by copying the data through userspace. In this respect, I wonder why ext4 enforces the "can't rename to a target directory with a different projid" restriction that XFS has? It seems possible (very beneficial even) to change the projid in ext4 when a file is renamed to a different directory, rather than forcing a full-file copy in userspace, which can be very slow if the file is large. Essentially the permission check for rename() could become "if user has write permission in the target directory with a different projid, then allow the change" since they could just as easily bypass the permissions in userspace. According to Dave's original post this is an "XFS implementation detail": https://www.spinics.net/lists/linux-ext4/msg44738.html XFS doesn't transfer the quota from projid to projid because it's borderline impossible to correctly track all the metadata allocation/free operations that can happen in a rename operation and account them to the correct quota. Hence all those corner cases are avoided by treating it as EXDEV and forcing userspace to cp/unlink the files rather than rename. That's really an implementation detail. If we don't have this problem in ext4 then we don't need to return -EXDEV. However, that is digressing from the original point of "restrict permission" rather than "allow for rename". > 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 > allowed". IMHO, if any user can arbitrarily change the projid of a file, that prevents effective project quota enforcement. > 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 > for? No, but at the risk of bike-shedding this too much in advance of actual user need for a more complex mechanism, preventing users from arbitrarily shedding quota to other projects seems very useful. The restrictive and traditional method is to allow only root (uid==0) to do this, but modern systems try to avoid this by using e.g. CAP_SYS_RESOURCE (which is used for other quota changes). A slightly more flexible method would be to allow a group (e.g. "wheel" or "admin") to also control project IDs for files/directories. This would default to GID=0 to start (root only), or could default to GID=-1 (any group can change) to match the current behavior. Defaulting to GID=-1 would have the benefit that the mechanism for restricting "setprojid" could be added but keep the same behavior as today, but make it easy to change if desired. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
