The early Unix history of chown() being restricted to root
utcc.utoronto.ca
The early Unix history of chown() being restricted to root
1–10 of 41 posts
Re: The early Unix history of chown() being restricted to root
#2It was one of those restrictions that seemed unjustified to me but I figured someone smarter than I had seen a reason.
Re: The early Unix history of chown() being restricted to root
#3> Forbidden
> You don't have permission to access /~cks/space/blog/unix/ChownRestrictionEarlyHistory on this server.
I laughed out loud.
https://web.archive.org/web/20251018101005/https://utcc.utor...
Re: The early Unix history of chown() being restricted to root
#4It was one of those restrictions that seemed unjustified to me but I figured someone smarter than I had seen a reason.
Yeah.. I'm sitting here wondering how many years would it take to remove equally stupid error that says 'private key permissions too open' from ssh-add and friends.
Would save me a wrapper script on my flashdrive that does hacks like loading it from stdin or moving it to temp file.
Re: The early Unix history of chown() being restricted to root
#5Not 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 that we'd keep changing the owner of their files. If only the semantics of the unix filesystem supported file generation numbers, like on Tops20 or VaxVMS, where the default for writing to a file isn't "yeah, sure, write over top of the old data, and let's hope nothing fails along the way" this would not have been a problem.
Re: The early Unix history of chown() being restricted to root
#6Wait. You can use chown as non root?
Re: The early Unix history of chown() being restricted to root
#7It was one of those restrictions that seemed unjustified to me but I figured someone smarter than I had seen a reason.
Yeah.. I'm sitting here wondering how many years would it take to remove equally stupid error that says 'private key permissions too open' from ssh-add and friends. Would save me a wrapper script on my flashdrive that does hacks like loading it from stdin or moving it to temp file.
It's just a nice security measure.
Re: The early Unix history of chown() being restricted to root
#8It 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
Re: The early Unix history of chown() being restricted to root
#9If 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.
Re: The early Unix history of chown() being restricted to root
#10It 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.