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