The early Unix history of chown() being restricted to root • Hacker News Board

Re: The early Unix history of chown() being restricted to root

#11

Post by heythere22 » Sat, Oct 18, 2025, 4:43 PM UTC

kazinator wrote: post #9

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 n…

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?

Re: The early Unix history of chown() being restricted to root

#12

Post by SoftTalker » Sat, Oct 18, 2025, 4:43 PM UTC

drfuchs wrote: post #5

Not being able to chown() caused us grief developing Frame Maker back in the 80s. The responsible way to handle "save" was to write the document into a new file mydoc.new, then rename mydoc.cur to mydoc.backup and then rename mydoc.new to mydoc.cur, so that failure never left you in the lurch. The only problem was that there was no way to create mydoc.new to have the same owner as mydoc.cur and customers complained t…

I would guess that many early systems just didn't have the storage space for a lot of multiple versions of files. Was VMS saving diffs or full copies of files?

Once storage space was plentiful, the pattern of "overwrite the existing file" was already well established.

Re: The early Unix history of chown() being restricted to root

#13

Post by kazinator » Sat, Oct 18, 2025, 4:51 PM UTC

heythere22 wrote: post #11

kazinator wrote: post #9

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 n…

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?

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.

Re: The early Unix history of chown() being restricted to root

#14

Post by webdevver » Sat, Oct 18, 2025, 5:12 PM UTC

drfuchs wrote: post #5

Not being able to chown() caused us grief developing Frame Maker back in the 80s. The responsible way to handle "save" was to write the document into a new file mydoc.new, then rename mydoc.cur to mydoc.backup and then rename mydoc.new to mydoc.cur, so that failure never left you in the lurch. The only problem was that there was no way to create mydoc.new to have the same owner as mydoc.cur and customers complained t…

ive always felt that file systems are by far the weakest point in the entire computing industry as we know it.

something like zfs should have been bog standard, yet its touted as an 'enterprise-grade' filesystem. why is common sense restricted to 'elite' status?

ofcourse i want transparent compression, dedup, copy on write, free snapshots, logical partitions, dynamic resizing, per-user/partition capabilities & qos. i want it now, here, by default, on everything! (just to clarify, ive ever used zfs.)

its so strange when in the compute space you have docker & cgroups, software defined networking, and on the harddrve space i'm dragging boxes in gparted like its the victorian era.

why can't we just... have cool storage stuff? out the box?

Re: The early Unix history of chown() being restricted to root

#15

Post by pessimizer » Sat, Oct 18, 2025, 5:31 PM UTC

webdevver wrote: post #14

drfuchs wrote: post #5

Not being able to chown() caused us grief developing Frame Maker back in the 80s. The responsible way to handle "save" was to write the document into a new file mydoc.new, then rename mydoc.cur to mydoc.backup and then rename mydoc.new to mydoc.cur, so that failure never left you in the lurch. The only problem was that there was no way to create mydoc.new to have the same owner as mydoc.cur and customers complained t…

ive always felt that file systems are by far the weakest point in the entire computing industry as we know it. something like zfs should have been bog standard, yet its touted as an 'enterprise-grade' filesystem. why is common sense restricted to 'elite' status? ofcourse i want transparent compression, dedup, copy on write, free snapshots, logical partitions, dynamic resizing, per-user/partition capabilities & qos. i…

Because it was extremely difficult to create something like zfs? And it was proprietary and patent-encumbered, and the permissively licensed versions were buggy until about 5 minutes ago?

That's like saying the Romans should have just used computers.

Re: The early Unix history of chown() being restricted to root

#16

Post by JadeNB » Sat, Oct 18, 2025, 5:55 PM UTC

TZubiri wrote: post #8

ape4 wrote: post #2

It was one of those restrictions that seemed unjustified to me but I figured someone smarter than I had seen a reason.

Imagine if you wanted to enter a bank safe, but your key doesn't fit the lock. If you were able to change the lock, you would bypass the lock mechanism, rendering it useless

But imagine if you were the bank-safe owner. Shouldn't you be able to change the lock?

Re: The early Unix history of chown() being restricted to root

#17

Post by charcircuit » Sat, Oct 18, 2025, 5:56 PM UTC

rcxdude wrote: post #10

ape4 wrote: post #2

It was one of those restrictions that seemed unjustified to me but I figured someone smarter than I had seen a reason.

It would need at least a little bit of thought with suid binaries.

Suid binaries were a bad idea and should be removed anyways.

Re: The early Unix history of chown() being restricted to root

#18

Post by SoftTalker » Sat, Oct 18, 2025, 6:09 PM UTC

webdevver wrote: post #14

drfuchs wrote: post #5

Not being able to chown() caused us grief developing Frame Maker back in the 80s. The responsible way to handle "save" was to write the document into a new file mydoc.new, then rename mydoc.cur to mydoc.backup and then rename mydoc.new to mydoc.cur, so that failure never left you in the lurch. The only problem was that there was no way to create mydoc.new to have the same owner as mydoc.cur and customers complained t…

ive always felt that file systems are by far the weakest point in the entire computing industry as we know it. something like zfs should have been bog standard, yet its touted as an 'enterprise-grade' filesystem. why is common sense restricted to 'elite' status? ofcourse i want transparent compression, dedup, copy on write, free snapshots, logical partitions, dynamic resizing, per-user/partition capabilities & qos. i…

Because the vast majority of personal computer users have no need for the complexity of zfs. That doesn't come for free, and if something goes wrong the average user is going to have no hope of solving it.

FAT, ext4, FFS, are all pretty simple and bulletproof and do everything the typical user needs.

Servers in enterprise settings have higher demands but they can afford an administrator who knows how to manage them and handle problems. In theory.

Re: The early Unix history of chown() being restricted to root

#19

Post by toast0 » Sat, Oct 18, 2025, 6:48 PM UTC

webdevver wrote: post #14

drfuchs wrote: post #5

Not being able to chown() caused us grief developing Frame Maker back in the 80s. The responsible way to handle "save" was to write the document into a new file mydoc.new, then rename mydoc.cur to mydoc.backup and then rename mydoc.new to mydoc.cur, so that failure never left you in the lurch. The only problem was that there was no way to create mydoc.new to have the same owner as mydoc.cur and customers complained t…

ive always felt that file systems are by far the weakest point in the entire computing industry as we know it. something like zfs should have been bog standard, yet its touted as an 'enterprise-grade' filesystem. why is common sense restricted to 'elite' status? ofcourse i want transparent compression, dedup, copy on write, free snapshots, logical partitions, dynamic resizing, per-user/partition capabilities & qos. i…

All of those things come with tradeoffs.

Compression tradesoff compute vs i/o, if your system has weak compute, it's a bad deal. Most modern systems should do well with compression.

Dedupe needs indexing to find duplicates and makes writes complex (at least for realtime dedupe). I think online dedupe has pretty limited application, but offline dedupe is interesting.

Copy on write again makes writes complex, and tends to fragmentation of files that are modified. Free snapshots are only free when copy on write is the norm (otherwise, you have to copy on write while a snapshot is open, as on FreeBSD UFS). Copy on write offers a lot, but some applications would suffer.

Dynamic resizing (upwards) is pretty common now. Resize down less so. Zfs downsizing is available, but at least when I tried it, the filesystem became unbootable, so maybe not super useful IMHO.

Logical partitions, per user stuff, qos adds complexity probably not needed for everyone.

Re: The early Unix history of chown() being restricted to root

#20

Post by siebenmann » Sat, Oct 18, 2025, 6:52 PM UTC

heythere22 wrote: post #11

kazinator wrote: post #9

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 n…

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?

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