I maintain a lot of FreeBSD ports and packages and have had to allocate a lot of service user accounts. I cant think of a single service I’ve ever run that could use a dynamic user. It either needs to access other services / data, others need to access it at some point, or it needs persistent data storage to work correctly in a way that doesn’t fit their design. None of these could use an ephemeral user account because I need a static UID and maybe persistent group membership.
I’m lost as to who would want or need this feature. What if I’m also restricting access at the firewall by the UID? What if I’m enforcing certain rules in the MAC framework by the UID? Am I crazy?
It either needs to access other services / data, others need to access it at some point, or it needs persistent data storage to work correctly
If you read the post, he goes over in detail how to do persistent data storage. I think you’re not crazy, but you didn’t read carefully. If you’re relying on static UIDs, you obviously wouldn’t configure dynamic UIDs, so I’m not sure what your point is there.
In addition to being useful for networked services (you could run nginx, apache, dns, email, etc.), you can also configure ReadWritePaths= or ReadOnlyPaths= to write to locations outside the sandbox (for example, creating a unix socket to communicate with other processes).
I did read carefully and their design for persistent data storage is very limited.
Also, what if my nginx uses fastcgi? How to handle a write access to the socket? Now I have to make the socket world-writable because I can’t permanently control the UID and GID of the daemon.
This is solving problems almost nobody has. It feels like if only works for simple ephemeral containers which I have no use for.
TL;DR: you may now configure systemd to dynamically allocate a UNIX user ID for service processes when it starts them and release it when it stops them. It’s pretty secure, mixes well with transient services, socket activated services and service templating.
This feature looks like it will enable some nice security benefits. However I’m a little concerned about the implementation (recursive chown’s, hashing usernames to get UID’s, reusing UID’s where possible, still relatively small UID space). As I read it I got the feeling that I would see this feature described in detail at the bottom of a very long postmortem debugging story about some pathological performance issues they ran into.
So this was considered not that long ago actually. It doesn’t quite have the semantics one wants. Sometimes one user can actually have less privilege than “any” user. We’re not really running out of IDs anyway. I had another proposal for something I was calling “ghost” processes, which is very similar except they would simply fail all user checks. More like UID == NaN. But 99% of the use case is covered by pledge forbidding those operations outright.
I maintain a lot of FreeBSD ports and packages and have had to allocate a lot of service user accounts. I cant think of a single service I’ve ever run that could use a dynamic user. It either needs to access other services / data, others need to access it at some point, or it needs persistent data storage to work correctly in a way that doesn’t fit their design. None of these could use an ephemeral user account because I need a static UID and maybe persistent group membership.
I’m lost as to who would want or need this feature. What if I’m also restricting access at the firewall by the UID? What if I’m enforcing certain rules in the MAC framework by the UID? Am I crazy?
If you read the post, he goes over in detail how to do persistent data storage. I think you’re not crazy, but you didn’t read carefully. If you’re relying on static UIDs, you obviously wouldn’t configure dynamic UIDs, so I’m not sure what your point is there.
In addition to being useful for networked services (you could run nginx, apache, dns, email, etc.), you can also configure
ReadWritePaths=orReadOnlyPaths=to write to locations outside the sandbox (for example, creating a unix socket to communicate with other processes).I did read carefully and their design for persistent data storage is very limited.
Also, what if my nginx uses fastcgi? How to handle a write access to the socket? Now I have to make the socket world-writable because I can’t permanently control the UID and GID of the daemon.
This is solving problems almost nobody has. It feels like if only works for simple ephemeral containers which I have no use for.
What could go wrong?
This feature looks like it will enable some nice security benefits. However I’m a little concerned about the implementation (recursive chown’s, hashing usernames to get UID’s, reusing UID’s where possible, still relatively small UID space). As I read it I got the feeling that I would see this feature described in detail at the bottom of a very long postmortem debugging story about some pathological performance issues they ran into.
Well this seems like a neat idea with no likely downsides except that it’ll make the output of
mounteven longer.Increased complexity.
Interesting concept, I wonder why OpenBSD didn’t already do it :) Does it provide too little benefit?
So this was considered not that long ago actually. It doesn’t quite have the semantics one wants. Sometimes one user can actually have less privilege than “any” user. We’re not really running out of IDs anyway. I had another proposal for something I was calling “ghost” processes, which is very similar except they would simply fail all user checks. More like UID == NaN. But 99% of the use case is covered by pledge forbidding those operations outright.