On Tue, Apr 06, 2021 at 11:46:55PM +0000, Andrew Beltrano wrote:
> When the wpa conf file is a symbolic link, the link is clobbered when
> written. This occurs because the rename() of the (regular) tmp file
> used to write changes replaces the original file, thus discarding the
> link.
>
> Fix this by first resolving the conf file link target (if any), and
> using the target as the defacto file path instead of the link file
> itself. This ensures the tmp file is created on the same filesystem
> as the link target, which is required for rename().
> diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c
> @@ -1545,15 +1545,23 @@ int wpa_config_write(const char *name, struct wpa_config *config)
> + } else if (read_link_target(name, &link_target) < 0) {
> + wpa_printf(MSG_ERROR, "Failed to read '%s' link target for writing", name);
> + return -1;
> + }
How should this behave on platforms that do not support symbolic links
(see the comment on patch 1/2)? Should this skip that error return and
continue without overriding the name pointer?
I'm also a bit hesitant on this type of design that is not really atomic
since that symlink case would seem to have a potential race condition if
the symlink is replaced between this read_link_target() call and the
rename(). If that were to happen, the original file might not be
modified at all. That might be fine in this particular case since the
target file is supposed to be in a directory that has limited write
access, but anyway, it would be good to be clear on the expectations for
that.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
