Hey peanut gallery! systemd-appd explained in a few sentences: https://blog.sebastianwick.net/posts/so-peerpidfd-gets-more-useful/

I will not take questions.

SO_PEERPIDFD Gets More Useful

A while ago I wrote about the limited usefulness of SO_PEERPIDFD. for authenticating sandboxed applications. The core problem was simple: while pidfds gave us a race-free way to identify a process, we still had no standardized way to figure out what that process actually was - which sandbox it ran in, what application it represented, or what permissions it should have. The situation has improved considerably since then. cgroup xattrs Cgroups now support user extended attributes. This feature allows arbitrary metadata to be attached to cgroup inodes using standard xattr calls.

swick's blog
@swick one thing I do like about dedicated sockets (like security-context-v1) is that they're kinda capability-shaped (in the proper sense not the silly linux caps sense) (very vaguely and weakly but still).. But yeah, a general "what sandbox is on the other end of the socket" API is a very practical need right now

@valpackett @swick IMO security-context is closer to appd than to capabilities as you mean them. It's all about attaching the app's identity to the socket connection. The compositor knows who the app is and this can enforce policy on it

appd is the same thing, but made generic. Instead of having N protocol-specific ways to attach an app's identity to a given socket connection, we build out a mechanism to query an app's identity given any connection

Thus they're fundamentally the same thing

@AdrianVovk @swick right, you can attach metadata in security-context, but that's sort-of optional in practice? Many compositors don't really care about app identity, e.g. in Sway the only policy is "if connected from security-context, then hide all 'privileged' protocols like layer-shell", nothing more complicated, so effectively that new socket is a strictly-reduced-capability one vs. the original connection

@valpackett @swick Sounds like anti-capabilities :p. Holding the special socket takes away your capability to do privileged actions, rather than granting you the capability to do the actions

Anyway on a more practical note the Wayland compositor can do exactly the same thing with appd. Check if the incoming client is any sandboxed app, if yes hide the privileged protocols, if no don't. No need to look at all the metadata if you don't need it. But boy is it useful to have right there if you do

@AdrianVovk @swick "takes away" is the entire point. capabilities are unforgeable handles (such as file descriptors) that can only be reduced in privilege (never elevated) and passed around (like fd-passing). I highly recommend reading up on capabilities-based security and playing with Capsicum on FreeBSD, just for fun and learning even. It's a really neat design.

@valpackett @swick Ah interesting. In the recent bus1 IPC proposal for Linux, "capabilities" are the fact that once you hold a handle to do something the fact that you possess that handle is what authenticates you to do that action.

Edit: it seems like we're talking about basically the same thing but from different perspectives

@AdrianVovk
- holding the "normal" socket gives you privileged access
- holding the special socket gives you limited access
- holding no socket gives you no access

and you can always move down in that list, but never up.

I think this matches the properties of a capability quite well.

Another important aspect of capabilities is you can pass a socket to someone else, giving them the same access as you have.
@valpackett @swick

@swick This is confusing. The blog post does not even mention the name systemd-appd. But it mentions that the method does not depend on systemd, nevertheless you name it systemd-appd. Is there some repo where we can have a look at it?
@swick sounds like it's time to tap the sign again http://www.islinuxaboutchoice.com/
Is Linux About Choice?