|
Top-level
 … you cannot just delete a user and expect it's data to be gone too. Except, that of course you can, because in systemd we have this nice little DynamicUser= concept: if you turn that on for a service it will allocate a user transiently while the service is running, and make it go away once it terminates. By running the service inside a tight mount namespace with very minimal write access only the functionality makes sure that the file removal problem becomes manageable: 3 comments
… for regular users. The former is very similar: capsule@.service can be instantiated many times, and each will spawn a per-user service manager too – but has DynamicUser=1 set, i.e. it's a service manager for a dynamic, short-lived user. So, what is this good for? The idea is that you place some service definition files in the .config/systemd/user/ subdir of /var/lib/capsules/<somename>/. The latter becomes the $HOME of the dynamic user created for capsule@.service. With that in place, … … you can then do "systemctl start capsule@<somename>.service" to start the capsule. This spawns a per-user service manager, with a shortlived dynamic user. Once you do "systemctl stop capsule@<somename>.service" it goes away again. And inside that service manager all services defined and enabled in the aforementioned directory will be invoked. You don't really have to place service files in that dir btw. You can also just start the capsule as-is, and then invoke stuff dynamically inside… |
Gregory's Server
if your service/dynamic user can only write to some very specific private directories, you can just delete those and be sure nothing of that dynamic user will persist.
So, what are those "capsules" then, that this story was all about? Well, it combines the concept of the per-user service manager and the concept of DynamicUser= into one thing: there's now a new template service capsule@.service which is very similar to user@.service. The latter wraps the per-user service manager…