My late, but revealing discovery of importance of batch file renaming, described in the previous blog post, inspired me to take a closer look at other FileUtils features, which I implemented just because I needed them or users asked for them, but without really thinking about their importance and how much they can make work of many users easier. This time I will address POSIX file permissions - the feature I needed myself and decided to implement it in a small application, consequently initiating what would become the full-fledged application.
First, some terminology here. There are several ways in which file permissions bits on macOS are referred to. The first one is simply file permissions, not implying any specific standard or operating system. It is commonly seen in general documentation, tutorials, and conversation. The next one, is UNIX permissions, which is probably the most commonly used informal term. It refers to the traditional permission model introduced in UNIX operating system. Finally, there is POSIX permissions, which is the most standards-accurate term. It refers to the file permission model defined by the IEEE POSIX specification, which formalized the traditional UNIX behavior. I decided to use the latter one (across FileUtils website as well) due to its most technically precise nature.
POSIX permissions may seem like totally unimportant feature, considering that overwhelming majority of Mac users use their Macs in a single-user mode, not caring much who can access various files as there is just one user anyway. However, under the hood, there are many more users (processes) in macOS (UNIX) and having correct POSIX permissions for many system and library files is crucial for correct functioning of the system. That is especially evident if one encounters "incorrect file permissions" issue, which needs fixing either by the system or manually. POSIX permissions are also essential if a single Mac is used by two or more people under different user accounts, as well as if a single/multi-user Mac is a part of a computers network.
Historically, POSIX permission came to Mac with introduction of Mac OS X in 2001. Before that, classic Mac OS was fundamentally a single-user system, so it did not implement per-user file permissions. Its HFS filesystem didn't support any notion of file permissions. If files were shared over AppleShare, the server could apply some access privileges. But these were managed by the server and not the filesystem and they were not stored as UNIX (or any other) style mode bits. However, even when Mac OS X was introduced, having fully supported POSIX permission bits on a filesystem (HFS+) level, Apple never really cared to expose the full power of POSIX permission to users. If one wasn't willing to dive into the terminal, the Finder Get Info panel was essentially the only built-in UI for editing file permissions. However, it had several important limitations, allowing assignment of only three privilege levels: "Read & Write", "Read only" and "Write only (Drop Box)". These map to combinations of the underlying POSIX bits, but Finder does not expose the raw bitmask, so one cannot directly manipulate particular permission bits. Even the UI display can be misleading: Finder shows a simplified summary of permissions rather than the full POSIX state. Starting with Mac OS X Tiger (10.4), Apple introduced Access Control Lists (ACL) to support more flexible permissions and Finder gained support (again, limited) for it, but that created some new ambiguities in the process. Anyway, that might make for a nice story for some other blog post.
Due to some regular work and necessity to maintain a few small Mac networks, I need to change POSIX permissions of various files on various Macs quite often. I have been doing that task in the terminal for a long time. But quite occasionally the necessity to change POSIX permissions, sometimes even to propagate them down a folder hierarchy, came while I was doing some file management in Finder. I needed to switch to terminal and position myself into the right directory before completing the task. Having some quick way to do all that in Finder seemed like godsend to me. When this experience started getting frustrating, I decided to take matters into my own hands and do something about it. And that's how FileUtils essentially started its life. It presents rich user interface, which allows for full manipulation of all POSIX permission bits, as well as changing file's owner and group. Permission bits can be changed by clicking appropriate checkbox, but the whole bitmask can also be manipulated by simply typing octal permission value, just like in terminal chmod command. It is interesting to note the first implementation of FileUtils didn't support manipulation of setUID, setGID and Sticky bits, since I rarely needed to change those. Support for these was added later (in version 1.5.2) due to users request. That just proved how important POSIX permissions are to many users and implementing them was the right thing to do.
While I'm on the subject of these "special" bits, whose purpose isn't very obvious at first look, it may be interesting to mention some neat historical quirks. They were not all introduced at the same time, and their meanings evolved quite a bit during early UNIX history.
• The set-user-ID bit (setUID) appeared very early in UNIX history. Its purpose was to allow ordinary users to run programs that temporarily execute with another user's privileges, usually root. The classic example, still in use today, is the passwd command. Changing a password requires writing to a "special" file that normal users cannot modify. The passwd program/command is owned by root and marked setUID, so when run by ordinary user, it runs with root's effective UID, thus ensuring writing into the special file. This mechanism became a cornerstone of the UNIX privilege model, long before more modern privilege systems existed.
• The set-group-ID bit (setGID) was introduced after setUID. It serves two purposes: on executables it is similar to setUID, but affects the effective group ID of the process. This was historically useful for programs that needed group-level privileges instead of full root access. On directories (behavior introduced later), it adds very useful feature of files created in a directory inheriting the directory's group. This behavior is widely used for shared project directories on UNIX systems.
• The Sticky bit has the strangest history. Originally, on early UNIXes and on executables only, it meant something like "keep the program's text segment in swap after execution." This allowed faster (consecutive) program startup because the program's code stayed in memory. This made sense on machines of that time, where disk I/O was slow and memory was scarce. With hardware improvements, this functionality became somewhat obsolete, so later UNIX systems repurposed the sticky bit for directories. Today it means: only the file owner, directory owner, or root may delete or rename files inside the directory. This prevents users from deleting each other's files in shared directories.
I hope this whole story about POSIX permissions was interesting on all three accounts: as an introduction, as a reminder and as a history walkthrough. In any case, if you need to manipulate POSIX permissions on your Mac and you would like to avoid switching into terminal for that task, give FileUtils a try, its POSIX permissions UI editor might be something you wanted for a long time.