[INFO] Mojave: UF_DATAVAULT / [Q] ACLs [DONE]

[JayB]

Some background information:

https://eclecticlight.co/2018/10/23/moj ... erability/
https://eclecticlight.co/2018/10/25/no- ... in-mojave/
https://mjtsai.com/blog/2018/10/25/moja ... datavault/

It seems this UF_DATAVAULT is a new kind of "flag". I'm not on Mojave yet, but I'm pretty sure the `ls` command will not print "datavault" like it prints "restricted", "schg" etc. But maybe there's a place in Nimble Commander's "File Attributes" panel to show the user when a file belongs to the super-protected "Data Vault" category. Maybe it can go between the flags section and the ownership section with an additional separator. (?)

While I'm at it: anything on the horizon regarding incorporating NC functionality to set/change/delete ACLs? I can see this in the File Attributes panel as well, maybe an additional button in the ownership section below "Group" that opens another panel to edit ACLs. Possible? (I believe a file manager should support ACLs, but maybe that's just me. )

[mike]

Ok, I added this flag into the File Attributes dialog (obviously as a read-only field).
Regarding ACL - nobody really uses them on Mac, so I see no reason to spend time on this functionality.

[JayB]

Thank you! Too bad about ACLs, though. I actually use them, mostly to restrict write access to certain folders, e.g. Desktop. Apple seems to use them a lot to protect default system folders, also in the user's home folder. It's actually an awesome tool to have finetuned control over your system. But if it's too much of a hassle to implement this, I can understand. But maybe a read-only string is possible in the File Attributes window? One additional line per access control entry, e.g.

Code: Select all

0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

below the flags or below the owner/group section? That way users will at least know if ACLs are used on a file. (Just an idea, though long ACL entries might be too long for a fixed width window.)

EDIT: or instead of printing the actual ACL, just a part-agnostic info like "ACL yes/no".

[JayB]

If you do change your mind at some point in the future, the interface would be straight-forward, something like this.



In the meantime, maybe I can cook up some solution for myself.

[mike]

Well, to be honest I'm very surprised you're actually using ACLs!
Implementing this feature might eat up to a month, there's no such time at disposal.
I also don't think it can be added to the File Attributes dialog, since it supports working with multiple entries and merging ACLs would be a nightmare.

[JayB]

I understand. Would be cool, though. And yeah, ACLs are actually pretty great. Apple uses them too for some system locations. I use them a lot on important folders, e.g. in my home directory like ~/Applications, ~/Developer, ~/Developer/Applications, ~/.cache, ~/.local, ~/.local/bin etc. It's a shame so few people use them.

I once had a command line installer that just wiped all contents of my ~/.config directory, so I'm not taking any chances: "everyone deny delete" is mostly my preferred access control entry. It's also good for protecting developers' LaunchDaemons, which I've modified, from being reset to default values by updaters etc. (Though I tend to use the system-immutable Unix flag there too.)

[JayB]

Another thing: Apple actually forces you to use the ACL method, if you want certain functionality. Way back when, maybe on Mac OS X 10.5. or 10.6 they removed the UNIX flag uunlnk (user no-unlink); it's still in the XNU source code, but commented out: https://github.com/opensource-apple/xnu ... #L475-L478

Code: Select all

* The following bit is reserved for FreeBSD.  It is not implemented
 * in Mac OS X.
 */
/* #define UF_NOUNLINK	0x00000010 */	/* file may not be removed or renamed */

Old Mac OS X man pages still have it, so it used to be implemented at some point. (Or Apple made a mistake in writing/porting the BSD man page?)

It's a great way to have editable files, and still protect them against accidental deletion, and no root privileges are needed.

But not on macOS. If you want that, you need to use the ACL method. Which is a great method, but complex.