OSDev.org

I don't think that you can solve this by file ownership.

The best you can do is encryption. Then Bob on A uses a password to encrypt the file (not necessarily his account password, and the hash is NOT stored on the media), and Bob on B can only read it if he knows that password (which proves Bob B is the same as Bob A). For anybody else (regardless if the fs driver is implemented in a way that ignores file owners or not) the file would be readable, but garbage. This is a fundamentally different concept than file ownership, but yields the same result at the end of the day on removable media.

Cheers,
bzt

The central point is that there is no such thing, can be no such thing, and should be no such thing as a "global user account" or "global user ID". And that right there means that a medium that's not going "user A to user B, do you copy?" (point-to-point, like FTP / SFTP), but instead "user A to whom it may concern" (generic USB sticks, HTTP, hardcopy printouts, ...), cannot be supporting strong ownership.

Of course there _could_ be such a thing, doesn't mean there should though. We could easily setup an LDAP and make all devices use it.

I don't understand how ownership is related to "user A to whom it may concern", if user A is publishing something, then clearly it becomes public. User A may still retain some rights in terms of law, but once published it pretty much stays public. DRM could possibly help, but even that would have it's limit.

If I'm transferring files via USB stick, then why should I lose ownership? Either I'm transferring them between systems for myself, or I'm transferring ownership to someone else, both cases work with encryption. I don't really get what the problem here is.

You want to publish it, decrypt it. You want to retain ownership, keep it encrypted.

As for the OP, I'm not sure why he/she wants to use password hashes instead of actually encrypting the data.

This thread reminds me of the trouble I had due to UIDs stored in Tar archives when I was building my LFS system back in '02. I don't think sudo existed back then, so the only practical way was to build everything as root. So many of the tarballs had funky UIDs & GIDs, I got into the habit of running chmod -R 0:0 after every unpack. Most tarballs had sensible permission bits, but those that didn't caused me very surprising and weird problems as soon as I switched to my normal user. I've had UIDs like 161334 turn up in the most surprising places. I've also had ID annoyances migrating hard disks from one Linux distro to another; UID 100->1000; GID 100->1000->100 again. The ID changes are understandable in the context of 70s/80s Unix; less so when Plan 9 demonstrates it's possible to use usernames instead.

Here's my stance: If your data on your removable storage is private and you care about keeping it that way, encrypt it.* If it's for sharing but you want to use a filesystem with UIDs and permissions, I do not want to do business with you, thank you, bye bye. There are exceptions, such as a bootable OS image, but don't mess me around with fiddling details on individual files. Either share it or don't.

*: If necessary, store the key separately on each computer it will be used with. And don't plug it into a computer you don't trust.

Incidentally, Plan 9 doesn't have a concept of a superuser, but the hostowner can open the filesystem console and disable permission-checking! This doesn't apply to network drives. Plan 9 was designed around users using diskless "terminals" most of the time with auth and files handled by central servers; security is maintained by not giving users access to the media. It also results in users having the exact same environment at home as at the office (or lab); removable media is not necessary for sharing data. Dennis Ritchie used removable media for a different purpose. He used to carry around Plan 9 boot floppies so he could boot any conveniently nearby workstation as a Plan 9 terminal & get his normal work environment anywhere.