anon (no@thanks.com) on 1/29/09 wrote:
---------------------------
>Your security argument is bogus. Having xattrs would eliminate privacy worries
>much more than the present state of affairs. As things are, the metadata is the
>file bytestream travels with them, whether the user is aware of this or not (or whether the user _likes_ this or not.)
>
>But with xattrs, the desktop system security policy can wipe all xattrs from a
>file if it is being transferred to a non-local disk (or some other default system
>policy can be in effect) exactly because xattrs _are_ so transparent and non-proprietary.
>
>Like Duh.
>
>So go back to the silicon forest and take your holy penguin pee with you. You
>have demonstrated you obviously can't engage in critical thinking.

Everybody who is arguing against Linus is retarded. And it is damn funny to see a comment like this.

For the love of God, the question is not whether you can think hard enough to come up with a situation where xattrs might be usable to solve a particular problem. The question is whether xattrs can do things *significantly* better than the alternatives. They have to do it significantly better, because the alternatives are already existing and have applications tools etc for decades. There are also important downsides of xattrs which Linus mentions but is failed to be acknowledged ("oh but here is a scenario where you can use xattrs, so your disadvantage scenario is invalid"... what kind of bullshit is that??).

And the alternative to xattrs are: files and directories, metadata within the file, and metadata in external databases.

All examples brought up by the metadata proponents as far as I can see can be done equally well if not better with the above than with xattrs, so then xattrs have no *significant* advantage.

Actually, except for well integrated system security model, in which case, xattr basically just becomes a filesystem agnostic layer for whichever model is used (basically just in place of existing unix access metadata). Linus already acknowledged this case. Basically metadata that the OS has to know about, of course has to belong in this kind of space.

mp3 collection? directory per song would be nice, you could manage metadata easily with any tool. You explicitly choose which metadata to keep and which to drop if copying things around (which again, works with any utility or transfer protocol). The directories also needn't contain the actual data for the song if unavailable, but just a reference or checksum (eg. on cdrom or remote). An external database would be OK too -- at least that is an explicit choice and you get sane and expected semantics when using other utilities to manage the filesystem.

beagle/antivirus? Start with a simple, dumb implementation of an external database which loses information on renames. How is this worse than xattrs? With xattrs, the file owner pretty well must clear xattrs when copying/moving/changing permissions of the file, if the xattrs are created by an unknown external source. But in case you say that in some scenarios the user can retain this information to make those programs work better... obviously have zero clue about races and pitfalls in this area (hint: many), nor what it takes to make programs like this work well (hint: it is not to spread your metadata all over the disk with the files; why even fucking bother with an indexing program if you were going to do that?).

No, actually, beagle/antivirus type programs really want to track renames for themselves, they don't want to shit all over the filesystem, they don't want to shit on xattr space of all files (if xattrs were so good and everybody uses them for everything, then your indexing program needs to index the xattrs, as does your av program. nice). An external database is the best way to do it. I'd bet money that nobody can come up with a reason why not that doesn't involve whining and handwaving.

Your point about metadata travelling with bytestream. Duh. The point about a byte stream filesystem is that the application can encode their own data/metadata however they like. And the point is exactly that your cp, or mv, or cat, or ftp, etc is always explicitly going to do the expected thing (copy a word document from one place to another, and you explicitly ask to copy that word document which contains data and metadata as described by the app). How you can possibly turn this into a security advantage for xattrs is laughable. Use your damn brain and think for a minute what would a proposed implementation of all metadata in xattrs look like for a (for example) word document, and ask yourself how a user could possibly know enough to be able to strip out (for example) recently made changes to the document using command line xattr manipulations.

Remember before anybody posts again: nobody cares that you CAN use xattrs in specific scenario A. You have to make a case that xattrs are *significantly* better than the alternatives. No, not alternativE. No, not for scenario A if it is the only stupid implementation you could dream up after 5 minutes of barely thinking.