Since something's probably going to be said eventually, I'll do it this time. > ...how timesyncd is supposed to get access through an inaccessible directory. I

Since something's probably going to be said eventually, I'll do it this time. > ...how timesyncd is supposed to get access through an inaccessible directory. I'll quote the explanation for that: > > [Access through /var/lib/private] is achieved by invoking the service process in a slightly modified mount name-space: it will see most of the file hierarchy the same way as everything else on the system ([...]), except for /var/lib/private, which is over-mounted with a read-only tmpfs file system instance, with a slightly more liberal access mode permitting the service read access. [...] Reading this, I didn't quite completely facepalm, but... This solution - the high-level general architecture/approach; the ideas used - is, IMO, frankly insane. It means your running system's state can no longer be easily and straightforwardly reasoned about: no longer can you run a few commands and get a high level idea of what's configured (with respect to filesystems) and how everything's set up, see what files are where, and immediately know what a given file's permissions are. Instead, it seems you're now being expected to consider any arbitrary, given filesystem path you're puzzling over from the perspective of every FS namespace as viewed by each process (to be clear, this means every file * every namespace * every process). No sysadmin/devops type is going to do that; it's not sustainable. This architecture is bizarre enough that few tools will be built to do adequate introspection unless developers (glares at one in particular) actually extend and build on this further and additional even more wonderful breakage happens as a result, meaning that the tools must be created in order to keep systems manageable. Hopefully things don't get that bad? - but in the meantime said tools don't exist, so people get to to reverse-engineer PID 1 (AHEM) the Fun™ way, and keep all the half-square, half-circle pieces they discover along the way. Looking further afield, I'm more hesitant about the future of Linux as a viable trustworthy platform to have confidence in. I say that both from the perspective of straightforward enjoyable maintenance (which Linux is already struggling with) and from the perspective of reasonably consistent and surprise-free mental modelling to aid security best practice. UNIX was based on the idea of "everything's a file". Not, IMHO, the best/most efficient model; but okay. This... this blows that model out the window, because suddenly we have architectural interestingness being built on building blocks that exceed the scope of the original file model (look at a file, see the permissions of that file), but without pivoting/extending the basic building blocks of the system to incorporate the new models. Linux is still known as a UNIX clone, and the UNIX standards ("everything's a file" being fundamental) hasn't changed anytime recently, so this is... not dishonest, but definitely a potential source for a lot of confusion. And kind of technically dishonest. Furthermore, there's no defined direction for this new... standard? that seems to be appearing. I can't effectively model this seemingly byzantine architecture; I can't intuit landmarks or similarities from other systems (although I'll admit I've only used Linux, Windows and DOS). I do understand mount, PID and network namespacing. These concepts are not that difficult to reason about, in isolation. But they can be combined in very very unintuitive ways that make state analysis very difficult, and what I'm trying to express here is that I don't consider the architecture presented to be intuitive, easy to debug, or effective. (I never envisaged namespacing being used like this, of course.) Perhaps it was the simplest solution, in isolation, but it doesn't feel well-designed or thought through (with respect to sane diagnostics and transparent low-level housekeeping). Part of my freakout is that the tools available to examine namespaces are very target-specific; they don't consider the system as a whole. The question is whether the developers (briefly resumes glaring) nearest the namespace bits would be willing to maintain tools to help introspect at a holstic level. That may be needed soon. I guess the other part is that it feels Linux is getting really complicated. I think, based on my understanding of psychology, that this may be because I've been using Linux for a few years now (a decade or so), and my usage of it has perhaps become ingrained and rusted in place. Maybe so. But I do also wonder if the bazaar has scaled to the point where nobody can keep track of all the pieces as they move forward.