I’ve been spending some time recently investigating what would be required to strictly confine cloud-init (you can see my exploratory work here).
As you can see in that link, I’ve granted the account-control
interface to the snap, but for the account control parts of cloud-init to run successfully, I’ve found a couple of gaps to make passwd
work (which I filled using a system-files
interface):
- write access to
/etc/.pwd.lock
was required
-
passwd
also expects to be able to write a temporary file of the form /etc/shadow.NNNNN
; the only way I found to express write access to this via system-files
was to make all of /etc
writable
- (This line is commented out in the linked MP, because it obviously made it difficult to identify any other files in
/etc
that I might need different permissions on)
Should the account-control
interface include rules for these files by default?
AFAIK account-control
is for user management on core, where /etc/
isn’t writable at all; you’re expected to use extrausers for everything.
1 Like
If that is the case, then we should probably update https://docs.snapcraft.io/the-account-control-interface/7746 to make that clearer.
@chipaca is correct, but the interface is exposed on classic. There is a historical context with this interface. @niemeyer expressed a concern about the wide access the interface provides which is why today we have this comment in the policy:
# Only allow modifying the non-system extrausers database
We probably/possibly shouldn’t be exposing it on classic… I think what is needed (and @pedronis and/or @niemeyer can comment/correct me) is for snapd to gain an api for creating users on the snap’s behalf so it is in a position to mediate what is created and how (eg, system users with disabled passwords, etc). With all that in place, then cloud-init could talk to snapd. There would need to be design work on what cloud-init requires (AIUI, it can configure users in all kinds of ways) and how snapd would mediate that.
1 Like
I’ll also mention that working with extrausers is one thing, but working with system users is another, especially considering the wide privileged write access to things like /etc/passwd, /etc/shadow, creating/deleting arbitrary home directories, etc.
1 Like
I’ve just updated it. @jdstrand, @chipaca, how does that look to you?