Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 41 posts

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

#31

Post by rwmj »

charcircuit wrote: post #17
rcxdude wrote: post #10

Earlier quoted context omitted.

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

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

They're elegant at first glance, it's just the attack surface of "exec this other program" turns out to be enormous. eg. You wouldn't necessarily think that you'd have to clean out all environment variables, but what if your program is linked to some library that tries to parse some obscure environment variable and that parser has a bug. And the list goes on.

The alternative is sending messages to daemons, but as it turns out, the attack surface of those is pretty large too, albeit not as large as setuid.

The whole "do some work on my behalf with elevated privs" is not exactly a solved problem in Unix.

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

#32

Post by mixmastamyk »

SoftTalker wrote: post #25
mixmastamyk wrote: post #21

Earlier quoted context omitted.

FAT bulletproof? The newest versions have a few improvements but this is a line of filesystems for disposable sneakernet data.

Maybe bulletproof is a bit strong but I mean, it was fine on DOS/Windows for decades. I never lost data due to filesystem corruption on those computers. Media failures, yes frequently in the days of floppy disks.

Running scandisk and chkdsk was also a thing for decades. Luckily the lost sectors were often in unimportant files. But definitely a gamble.

The bulk of the safety came from the redundancy of copying the file across machines, not filesystem protections.

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

#33

Post by JadeNB »

TZubiri wrote: post #26
JadeNB wrote: post #16

Earlier quoted context omitted.

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

That would be what root is. I think a more appropriate question would be, if the key fits, couldn't you change the lock? Maybe, that would give you 3 abilities. 1 Lock yourself out if you please? Not terrible 2 Provide access to others, which makes sense since you already have access to the file, you could theoretically share it through other channels, you naturally cannot prevent this. 3. Lock others out. This one i…

> That would be what root is.

In this analogy, I think the analogue of the owner of the bank safe is the owner of the file. Unless you're envisioning the bank safe as representing all the files, rather than just one ...?

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

#34

Post by IshKebab »

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…

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?

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

#35

Post by TZubiri »

JadeNB wrote: post #33
TZubiri wrote: post #26

Earlier quoted context omitted.

That would be what root is. I think a more appropriate question would be, if the key fits, couldn't you change the lock? Maybe, that would give you 3 abilities. 1 Lock yourself out if you please? Not terrible 2 Provide access to others, which makes sense since you already have access to the file, you could theoretically share it through other channels, you naturally cannot prevent this. 3. Lock others out. This one i…

> That would be what root is. In this analogy, I think the analogue of the owner of the bank safe is the owner of the file. Unless you're envisioning the bank safe as representing all the files, rather than just one ...?

No, the bank owns and administers each safe, they lease it to you. They would be root.

UNIX ownership isn't necessarily legal ownership, files are not real property.

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

#36

Post by Izkata »

IshKebab wrote: post #34
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…

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?

Not if the file is in the shared /tmp/

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

#37

Post by 1718627440 »

Dylan16807 wrote: post #29
toast0 wrote: post #19

Earlier quoted context omitted.

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…

> 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. Older systems with worse compute also had worse i/o. There are cases where fast compression slows things down, but they're rare enough to make compression the better default.

I certainly don't want my compiler to get slower, because we now compress the files that are gone in a few minutes anyway. Compression is useful for archiving files, but for anything that you currently work with, it's useless and only wastes compute.

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

#38

Post by Dylan16807 »

1718627440 wrote: post #37
Dylan16807 wrote: post #29

Earlier quoted context omitted.

> 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. Older systems with worse compute also had worse i/o. There are cases where fast compression slows things down, but they're rare enough to make compression the better default.

I certainly don't want my compiler to get slower, because we now compress the files that are gone in a few minutes anyway. Compression is useful for archiving files, but for anything that you currently work with, it's useless and only wastes compute.

If you're limited by your SSD, one core running lz4 (or zstd) will double your write speed for object files. If you're not writing hundreds of megabytes per second, then you'll barely notice the overhead at that phase while it makes later phases that load the data back snappier.

If everything fits in ram then compression could be postponed.

And for that area in between, where your files don't fit in ram but compressed they would fit in ram, compression can give you a big speed boost.

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

#39

Post by kazinator »

IshKebab wrote: post #34
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…

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?

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

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

#40

Post by 1718627440 »

Dylan16807 wrote: post #38
1718627440 wrote: post #37

Earlier quoted context omitted.

I certainly don't want my compiler to get slower, because we now compress the files that are gone in a few minutes anyway. Compression is useful for archiving files, but for anything that you currently work with, it's useless and only wastes compute.

If you're limited by your SSD, one core running lz4 (or zstd) will double your write speed for object files. If you're not writing hundreds of megabytes per second, then you'll barely notice the overhead at that phase while it makes later phases that load the data back snappier. If everything fits in ram then compression could be postponed. And for that area in between, where your files don't fit in ram but compresse…

That's true. I think less memory is often accompanied with less compute. For example "one core running" is 50% of my available compute.
Post reply on HN