Re: [PATCH BlueZ] Leave config files writable for owner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 06.12.24 um 10:46 schrieb Bastien Nocera:
On Thu, 2024-12-05 at 10:00 -0500, Luiz Augusto von Dentz wrote:
Hi Bastian, Emil,

On Thu, Dec 5, 2024 at 8:35 AM Fiona Klute <fiona.klute@xxxxxx>
wrote:

This is needed both so the owner can adjust config as needed, and
for
distribution builds to be able to move/delete files as part of the
build without adjusting permissions themselves. Limiting writes
from
the running service needs to be done in the systemd unit (already
the
case) or init script.

See also:
https://lore.kernel.org/linux-bluetooth/4d1206df-598b-4a68-8655-74981b62ecca@xxxxxx/T/
---
  Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 297d0774c..29018a91c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -32,7 +32,7 @@ confdir = $(sysconfdir)/bluetooth
  statedir = $(localstatedir)/lib/bluetooth

  bluetoothd-fix-permissions:
-       install -dm555 $(DESTDIR)$(confdir)
+       install -dm755 $(DESTDIR)$(confdir)
         install -dm700 $(DESTDIR)$(statedir)

  if DATAFILES
--
2.45.2

Any comments regarding these changes, shall we also use 0755 in the
systemd service?

That's fine, although the changes are really academic, as root/the
owner can write and move those files just fine, even without explicit
write permissions.

With chmod, yes. A build process that expects created directories to be
writable for the user running the build fails. Sure, it'd be possible to
add a workaround, but it's better to fix the issue at the source.

The point made about the stopping the running daemon from writing to
/etc is on point though, which could be fixed by something like:
diff --git a/src/bluetooth.service.in b/src/bluetooth.service.in
index 8ebe89bec682..ddaa9d444eed 100644
--- a/src/bluetooth.service.in
+++ b/src/bluetooth.service.in
@@ -15,7 +15,7 @@ LimitNPROC=1

  # Filesystem lockdown
  ProtectHome=true
-ProtectSystem=strict
+ProtectSystem=full
  PrivateTmp=true
  ProtectKernelTunables=true
  ProtectControlGroups=true

See
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ProtectSystem=
As I understand the documentation there "strict" implies "full":

If true, mounts the /usr/ and the boot loader directories (/boot
and /efi) read-only for processes invoked by this unit. If set to
"full", the /etc/ directory is mounted read-only, too. If set to
"strict" the entire file system hierarchy is mounted read-only,
except for the API file system subtrees /dev/, /proc/ and /sys/
(protect these directories using PrivateDevices=,
ProtectKernelTunables=, ProtectControlGroups=).

So switching from strict to full would actually weaken protection,
though /etc should be read-only either way.

Best regard,
Fiona






[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux