workstation-ostree-config

#720 Fix Bluetooth file receiving on Atomic Desktop variants
Closed by siosm. Opened by l0g0ff.
l0g0ff/workstation-ostree-config main  into  main

Download 720.patch

Bluetooth file receiving fails on Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic) with "Operation not permitted" errors when attempting to receive files via OBEX. The root cause is that obexd refuses to follow symbolic links for security reasons, and on atomic/immutable systems, /home is a symlink to /var/home.

This PR adds a systemd drop-in override for obex.service that enables the --symlinks flag for the obexd daemon. This allows obexd to follow symlinks and write files to the actual location: /var/home/user/.cache/obexd/

The fix is added to common.yaml in the postprocess section, ensuring it applies to all Fedora Atomic Desktop variants.

  • Original issue: https://github.com/L0g0ff/KompassOS/issues/61
  • Fedora Discussion: https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813
  • BlueZ source: https://github.com/bluez/bluez/blob/master/obexd/src/main.c#L151

This fix has been tested on KompassOS (Fedora Kinoite/Aurora based) and resolves the Bluetooth file receiving issue.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/654877e432434e81a31eedf1c4014dc8

1 new commit added

  • Update common.yaml

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/1294c82baaf54eb1acc67f4650e988e9

LGTM, this seems like a reasonable fix to me. Unfortunately, I don't have a device to test it with.

Mind squashing the formatting fix?

rebased onto 5b4bba7d2555006ea116f6f68d744a32489e1ee5

Hi lorbus,
Done! I squashed the formatting fix into the main commit.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/eb37136fe5774a6d92a21f6a1d958503

OK, this looks OK but I don't think we should carry it here. It's either a security issue and needs to be fixed upstream (and we should not enable that here) or it's not a security issue and then it should be enabled for all of Fedora.

Can you open an issue upstream to clarify what our options are here?

Can you check if fixing the home dir path (see https://pagure.io/fedora-kde/SIG/issue/159) helps here?

Hi siosm, I tested this - my $HOME is set to /home/username (affected by #159).

However, fixing #159 won't solve the Bluetooth issue. The problem is that /home → /var/home is a symlink, and obexd's path verification fails when symlinks are involved - regardless of the $HOME value.

See this discussion for context: https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813

The --symlinks flag is needed because of the atomic desktop architecture, not just incorrect $HOME settings.

Per https://github.com/bluez/bluez/blob/62fdc13ed2efb9f95c42f0b5ca6d773730d62eb1/obexd/src/main.c#L301-L308, this should be fixed if $HOME correctly evaluates to /var/home/$USER - i.e. there should be no symlink involved.

At this point, we are not going to merge that as is until a discussion is started upstream and more investigation is done. Please also open an issue in https://gitlab.com/fedora/ostree/sig/-/work_items to track this.

Pull-Request has been closed by siosm

this should be fixed if $HOME correctly evaluates to /var/home/$USER

That's true, but the problem is at least Anaconda Kickstart installer puts :/home/<user>: to the /etc/passwd` homedir field, even for ostree systems.
So maybe it should be addressed there, if it's easy enough.

Anyway, the problem is hard to debug and severe, so keeping the fix downstream until it's not fixed upstream is worth to consider.

Replied in https://github.com/fedora-silverblue/issue-tracker/issues/697#issuecomment-4101046251
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.