[kazinator]

If you could chown files to an arbitrary other user, you could use that to evade disk quotas.

The protocol for changing ownership should be two step.

1. The file is put into an "offered" state, e.g. "offered to bob". Only the owner or superuser can make this state change.

2. Bob can take an "offered to bob" file and change ownership to bob.

Files can always be in an offered state; i.e. have an offered user which is normaly equal to their owner. So when ownership is taken, the two match again.

[IshKebab]

Why would you use ownership data for disk quotas? That's crazy. It should be based on file location. Anything in the user's home directory comes out of their quota. I assume that's how it does work surely?

[kazinator]

What if Alice leave her home directory permissions open? Mallory can then move a large file there and have it assigned to Alice's quota.

I suppose it could work, but Mallory would then risk Alice blowing that file away (perhaps innocently, not even realizing it was Mallory's file).

[IshKebab]

If I leave my front door unlocked and you put a large cow in my house, it's taking up space in my house.

[Izkata]

Not if the file is in the shared /tmp/

[heythere22]

What's the deal with disk quotas? Saw that in the OT as well. Why would you measure folder size seperately for each and every user? Would it not be a lot easier to just use the disk space of a folder regardless of whomever the file belongs to?

[pwg]

Because, in the early days of Unix systems actually being used as multiple, simultaneous, user systems, you might have one group of users collaborating on a project, and they would have a shared directory (via the 'group' owner) where they would store shared items. Each user would create various files, and each file's space consumption was charged to that user, but the shared directory might contain multiple files each owned by different users (but all owned by the shared 'group' identifier, so the group could access them).

For a group shared directory, assigning the disk space usage of files therein to one single user (ignoring the aspect of "which single user do you pick") is unfair to that user (his/her allowed maximum disk space is consumed) while everyone else is not charged for their actual usage.

This all came about to try to enforce rules to prevent one (or a few) rogue users from using up all disk space on the system for themselves, leaving no one else with any disk space available for their own usage.

[kazinator]

It's not folder size that you measure, but a user's usage: how many blocks are occupied by files belonging to a certain user, no matter where they are.

That's what quotas are: per-user storage limits.

If Bob has a large file which is sitting in Alice's home directory, that counts toward's Bob's quota, not Alice's. If Bob could sneakily change the ownership to Alice, while leaving the permissions open so he could access the file, then the file counts toward Alice's quota.

[siebenmann]

One reason why Unix quotas are generally not maintained and imposed by path is that it's a lot easier to update quotas as things are created, deleted, modified, and so on if the only thing that matters for who gets charged is some attribute of the inode, which you always have available. This was especially the case in the 1980s (when UCB added disk quotas), because that was before kernels tracked name to inode associations in RAM the way they generally do today. (But even today things like hardlinks raise questions.)

(I'm the author of the linked-to article.)