Allow ls to list extattrs on a file

[sef]

Summary

This is inspired by macOS, as so many things I do are.

"ls -l" for a file will show an "@" if it has any EAs; note that, if there is an EA and an ACL, it only shows the @ (see above). I'm not sure about the language I used in the man page change.

"ls -l@" for a file will list the EAs (if any), using the format "<tab>namespace eaname<tab>easize".

[sef]

Oh, an example output:

sef@sef-bsd:~ % ls -l ea_test 
-rw-r--r--@ 1 sef  sef  6 May 10 12:48 ea_test
sef@sef-bsd:~ % ls -l@ ea_test 
-rw-r--r--@ 1 sef  sef  6 May 10 12:48 ea_test
	user test	5

[bcr]

OK from manpages.

[jilles]

bin/ls/ls.1

439–440

This sentence should be removed and instead the option should be included in the list of extension options in the STANDARDS section below.

bin/ls/print.c

237–243

POSIX.1-2016 XCU 4 Utilities ls calls this eleventh character the "optional alternate access method flag" and says that shall it be the empty string if there is no alternate or
additional access control method associated with the file; otherwise, it shall be a string
containing a single printable character that is not a <blank>. So unless the extended attribute affects access control it should not be mentioned here.

(On another note, some of the file flags (from st_flags) are additional access control mechanisms, so they should be reflected here; however, I don't think that should be done in this review.)

772–773

If you want to keep the change that makes the extra character not POSIX-compliant, then this comment is out of date.

878

Is it possible that we get a truncated list here if an extended attribute was added concurrently?

887

Perhaps it is better to allocate a fixed char ea_name[256] instead of a variable length array. Alternatively, allocate one byte more for ea_list and temporarily overwrite the byte after the name with '\0'.

[sef]

bin/ls/ls.1

439–440

The -o option is not.

bin/ls/print.c

237–243

I'm open to other suggestions. I know, from macOS, that I *like* being able to tell which entries have an ACL or extattr. I could just drop that part, and require -@, but that defeats some of the purpose in just doing a quick look.

878

Yes. There is no atomic operation to get them all, and no iteration function, unfortunately.

887

Changing it to a constant 256 byte buffer is ok, but I figure, we have dynamic allocation, so why not use it?

[sef]

bin/ls/ls.1

439–440

I meant, the -o option doesn't have that sentence removed. I'm adding the -@ option to the STANDARDS section, but since that's the only change so far, and we're still discussing the other issues, I haven't uploaded the new diff. Sorry and thanks!

[jilles]

bin/ls/ls.1

439–440

Hmm, the -o option is slightly different in that POSIX defines it with a different meaning but only under the XSI option.

bin/ls/print.c

237–243

There is no problem for any formal POSIX compliance (one simply ensures that the filesystem for the compliance test does not have any extended attributes) but I don't really like the idea of using the eleventh character for just any moderately unusual property of a file.

878

Such a situation may cause the below loop to read beyond the end of the buffer. This might then cause a crash, or worse.

[sef]

bin/ls/print.c

237–243

So... POSIX just says that if there is an alternate access control method, use a character other than " ". Extended attributes use an alternate access method -- different system calls, and "user" vs "system" namespaces. Since POSIX does not require a "+" there, only a character other than " ", I'm not sure how wrong it is.

I would like to *ask* someone, but my POSIX contacts are all long moved on to other pastures; is there a way to do so?

237–243

Well, ironically, I was thinking about adding in a check for the st_flags field, and if any of the access-protecting ones were set, to use yet another character, inspired by your earlier comment. I was thinking "*". Or '%', and use '*' to indicate more than one.

In terms of modifying the output of "ls -l", using that field does seem like the safest one, since the value isn't defined by anything, and there's a large base (macOS) that already uses it, we can't add a (default) extra field, and it doesn't really look like it would go with any of the existing fields.

[jilles]

bin/ls/print.c

237–243

XBD 4.5 File Access Permissions discusses access control, and is quite clear that it is about operations on a file being permitted or denied. That extended attributes use different functions for access is not relevant.

Unfortunately, the ls page uses the terms alternate and additional access control method, while the rest of the standard uses the terms alternate and additional access control mechanism.

You can ask questions on the Austin group mailing list: https://www.opengroup.org/austin/lists.html

[sef]

bin/ls/print.c

237–243

Ok, so if the issue isn't POSIX, then what is the issue?

As I said, I'm open to other suggestions, and I don't know of any place that would be particularly *better*. Can't add a field, and placing a marker on any of the other fields is likely to break more things. Maybe having both (e.g., "-rw-r--r--+@") works, but I come back to the fact that there is an existing system which uses the scheme I proposed here. And, to the fact that I find this information useful when listing files. Maybe nobody else does?

[sef]

Ping?

[sef]

Ping? Anyone?

[freqlabs]

If there is some critical need for a strictly compliant mode, perhaps the standard POSIXLY_COMPLIANT environment variable trick found throughout the tree can be used to skip the extattr extension.

[jilles]

I think the best way forward is to start with -@ first and leave -l output as it is, at first.

In D24801#566687, @freqlabs wrote:

If there is some critical need for a strictly compliant mode, perhaps the standard POSIXLY_COMPLIANT environment variable trick found throughout the tree can be used to skip the extattr extension.

Not sure how well that works in practice; it may be better to just drop POSIX compliance and document that instead.

[sef]

I think the best way forward is to start with -@ first and leave -l output as it is, at first.

Hm. Ok. Here's this: I have a subsequent change, which prints out ACLs when requested ("-l" and new option "-e"). Now, macOS doesn't print attributes if -e is given, but I don't have to follow that.

Or I can limit it based on POSIXLY_COMPLIANT. Either one seems reasonable to me.