Re: [PATCH 0/3] agent: add passphrase storage options
Matthias Kurz <[email protected]> Tue, 28 Apr 2026 13:46:24 +0200
| Newsgroups | dev.linux.lists.iwd |
|---|---|
| Message-ID | <CAO=2mx5fmUjU4zeiV-O5HH-=fEG0P=5CRSseKGYMjcmRWUjm6g@mail.gmail.com> |
Hi James, thanks for taking a look. > Do you anticipate additional options needing to be passed? Not immediately. > I'm not really liking the idea of adding another agent API. Another option > instead of a new DBus API could be that we have a main.conf option, > something like: > > [General].DisableStorage=true > > If NM is always providing the passphrase via the agent API I don't see > why we'd need to keep an option within the network profiles right? I understand the concern about adding another Agent D-Bus method only to carry one storage option. I also agree that if the agent is always able to provide the passphrase, then iwd should not necessarily have to persist that passphrase itself. I am less convinced that a global DisableStorage=true option is the right model though. That would apply to the whole iwd daemon, while the ownership question is really per profile. A system can have profiles that are managed directly by iwd and should keep the normal iwd behavior, and other profiles that are mirrored by an external manager such as NetworkManager. For the mirrored profiles, the external manager is the source of truth for the file contents and for the secret storage policy. For native iwd profiles, iwd should still be free to update them as it does today. A global option would also make deployment awkward, because enabling it for NetworkManager would affect existing hand-written or iwd-managed profiles on the same machine. Conversely, leaving it disabled means externally managed profiles can still be rewritten by iwd. I came up with a different approach that avoids adding a new Agent API: a per-profile [Settings].ExternallyManaged=true flag. With that flag, iwd still reads the profile and can use it for connection setup, but it does not update the file as a side effect of normal network operation. This makes sense independently of NetworkManager: if someone handcrafts an iwd profile and marks it externally managed, iwd should treat the file as externally owned (and treat it as read-only). If NetworkManager mirrors a profile into /var/lib/iwd, it can add the same flag and keep owning the contents. I will send a small patch series for this shortly. Thanks, Matthias