On Thu, Feb 22, 2024 at 09:45:32AM +0100, James Bottomley wrote: > On Wed, 2024-02-21 at 22:37 -0500, Kent Overstreet wrote: > > On Thu, Feb 22, 2024 at 01:33:14AM +0100, James Bottomley wrote: > > > On Wed, 2024-02-21 at 18:01 -0500, Kent Overstreet wrote: > > > > Strings are just arrays of integers, and anyways this stuff would > > > > be within helpers. > > > > > > Length limits and comparisons are the problem > > > > We'd be using qstrs for this, not c strings, so they really are > > equivalent to arrays for this purpose. > > > > > > > > > > > > > But what you're not seeing is the beauty and simplicity of > > > > killing > > > > the mapping layer. > > > > > > Well, that's the problem: you don't for certain use cases. That's > > > what I've been trying to explain. For the fully unprivileged use > > > case, sure, it all works (as does the upper 32 bits proposal or the > > > integer array ... equally well. > > > > > > Once you're representing to the userns contained entity they have a > > > privileged admin that can write to the fsimage as an apparently > > > privileged user then the problems begin. > > > > In what sense? > > > > If they're in a userns and all their mounts are username mapped, > > that's completely fine from a userns POV; they can put a suid root > > binary into the fs image but when they mount that suid root will be > > suid to the root user of their userns. > > if userns root can alter a suid root binary that's bind mounted from > the root namespace then that's a security violation because a user in > the root ns could use the altered binary to do a privilege escalation > attack. That's a completely different situation; now you're talking about suid root, where root is _outside_ the userns, and if you're playing tricks to make something from a user from outside the ns that is not representable in the ns visible in that ns, and now you're making that something suid, of course you're going to have trouble defining self consistent behaviour. So I'm not sure what point you were trying to make, but it does illustrate some key points. Any time you're creating a system where different agents can have different but overlapping views of the world, you're going to have some really fun corner cases and it's going to be hard to reason about. (if you buy me a really nice scotch somitem I'll tell you about fsck for a snapshotting filesystem, where for performance reasons fsck has to process keys from all snapshots simultaneously). So such things are best avoided, if we can. For another example, see if you know anyone who's had to track down what's keeping a mount alive, then the something was a systemd service running in a private namespace. Systems where we can recursively enumerate the world are much nicer to work with. Now, back to user namespaces: they shouldn't exist. And they wouldn't exist, if usernames had started out as a recursive structure instead of a flat namespace. But since they started out as a flat namespace, and only _later_ we realized they actually needed to be a tree structure - but we have to preserve for compatibility the _view_ of the world as a flat namespace! - that's why we have user namespaces. And you get all sorts of super weird corner cases like you just described. So let's take a step back from all that, and instead of reasoning from "what weird corner cases from our current system do we have to support" - instead, just seem what we can do with a cleaner model and get that properly specified. A good model helps you make sense of the world even in crazy situations. With that in mind, back to your bind mount thing: if you chroot(), and you try to access a symlink that points outside the chroot, what happens?
