Re: [systemd-devel] Getting delegated IPv6 prefix from systemd-networkd

On 23.10.2022 13.57, Arseny Maslennikov wrote: On Sun, Oct 23, 2022 at 09:30:16AM +0300, Topi Miettinen wrote: On 22.10.2022 15.55, Ian Pilcher wrote: On 10/19/22 17:05, Ian Pilcher wrote: (I know that systemd-networkd can allocate subnets from the delegated prefix to local interfaces

Re: [systemd-devel] Getting delegated IPv6 prefix from systemd-networkd

On 22.10.2022 15.55, Ian Pilcher wrote: On 10/19/22 17:05, Ian Pilcher wrote: I've managed to get systemd-networkd to request and IPv6 prefix from my ISP, and I can see it the journal.  Now I need to programmatically retrieve it, so that my home-grown scripts can set up the various routes,

Re: [systemd-devel] Getting rid of the /run/credentials mount

On 25.8.2022 22.42, Marc Haber wrote: Hi, the aide (https://github.com/aide/aide) tool builds checksums of files on the system and sends an alert if things change on the system. In the Debian package, this is done from cron. I would like to move that to a systemd timer and in passing use some

Re: [systemd-devel] [EXTERNAL] Re: [RFC] systemd-resolved: Send d-bus signal after DNS resolution

On 18.8.2022 19.39, Suraj Krishnan wrote: Hi all, I wanted to revive this thread and provide an update on the status of this feature/PR. The feature adds a mechanism for privileged users to monitor DNS resolutions on the system, by adding a new varlink interface that exposes a method for

Re: [systemd-devel] Q: Start network in chroot?

On 13.6.2022 11.09, Ulrich Windl wrote: Hi! Two questions: 1) Why can't I use "systemctl start network" in a chroot environment (e.g. mounting the system from a rescue medium to fix a defective kernel)? When I try I get: "Running in chroot, ignoring command 'start'" From

Re: [systemd-devel] the need for a discoverable sub-volumes specification

On 11.11.2021 19.27, Lennart Poettering wrote: On Mi, 10.11.21 10:34, Topi Miettinen (toiwo...@gmail.com) wrote: Doing this RootDirectory= would make a ton of sense too I guess, but it's not as obvious there: we'd need to extend the setting a bit I think to explicitly enable this logic

Re: [systemd-devel] the need for a discoverable sub-volumes specification

On 9.11.2021 23.03, Lennart Poettering wrote: On Di, 09.11.21 19:48, Topi Miettinen (toiwo...@gmail.com) wrote: i.e. we'd drop the counting suffix. Could we have this automatic versioning scheme extended also to service RootImages & RootDirectories as well? If the automatic versio

Re: [systemd-devel] the need for a discoverable sub-volumes specification

On 8.11.2021 17.32, Lennart Poettering wrote: Besides the GPT auto-discovery where versioning is implemented the way I mentioned, there's also the sd-boot boot loader which does roughly the same kind of OS versioning with the boot entries it discovers. So right now, you can already chose

Re: [systemd-devel] best way to enable dynamicuser on a large custom application

On 12.2.2021 4.31, Davis Roman wrote: Hello, I've been tasked to take a large application mostly written in C which had previously always run as root and now run it under dynamic user. My goal is to follow the "principle of least privilege" and figure out all the necessary individual

Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

On 16.12.2020 12.03, Ulrich Windl wrote: Jarkko Sakkinen schrieb am 15.12.2020 um 05:19 in Nachricht <20201215041903.ga21...@kernel.org>: On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: Topi Miettinen schrieb am 11.12.2020 um 12:46 in Nachricht <27796c04-249e-

Re: [systemd-devel] Creating executable device nodes in /dev?

On 11.12.2020 12.46, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote: On 9.12.2020 2.15, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: As a further argument, I just did this on a Fedora system: $ find /dev -perm

Re: [systemd-devel] Creating executable device nodes in /dev?

On 9.12.2020 17.14, Andy Lutomirski wrote: On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote: On 9.12.2020 2.42, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: As a further argument

Re: [systemd-devel] Creating executable device nodes in /dev?

On 9.12.2020 2.42, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: As a further argument, I just did this on a Fedora system: $ find /dev -perm /ugo+x -a \! -type d -a \! -type l No results

Re: [systemd-devel] Creating executable device nodes in /dev?

On 9.12.2020 2.15, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: As a further argument, I just did this on a Fedora system: $ find /dev -perm /ugo+x -a \! -type d -a \! -type l No results. So making /dev noexec doesn't seem to have any benefit. It's

Re: [systemd-devel] Creating executable device nodes in /dev?

On 8.12.2020 23.30, Andy Lutomirski wrote: On Dec 8, 2020, at 12:45 PM, Topi Miettinen wrote: On 8.12.2020 20.07, Andy Lutomirski wrote: On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote: On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 19, 2020 at 08:17:08AM

Re: [systemd-devel] Creating executable device nodes in /dev?

On 8.12.2020 20.07, Andy Lutomirski wrote: On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote: On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote: Hi udev people- The upcoming Linux SGX driver has a device node /dev

Re: [systemd-devel] Creating executable device nodes in /dev?

On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote: Hi udev people- The upcoming Linux SGX driver has a device node /dev/sgx. User code opens it, does various setup things, mmaps it, and needs to be able to create PROT_EXEC

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 26.10.2020 18.24, Dave Martin wrote: On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote: Hi, There is a problem with glibc+systemd on BTI enabled systems. Systemd has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny PROT_EXEC changes. Glibc

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 26.10.2020 16.52, Catalin Marinas wrote: On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote: On 23.10.2020 12.02, Catalin Marinas wrote: On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote: Regardless, it makes sense to me to have the kernel load the executable itself

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 23.10.2020 20.52, Salvatore Mesoraca wrote: Hi, On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote: SARA looks interesting. What is missing is a prctl() to enable all W^X protections irrevocably for the current process, then systemd could enable it for services with MemoryDenyWriteExecute

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 23.10.2020 12.02, Catalin Marinas wrote: On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote: Regardless, it makes sense to me to have the kernel load the executable itself with BTI enabled by default. I prefer gaining Catalin's suggested patch[2]. :) [...] [2]

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 22.10.2020 23.02, Kees Cook wrote: On Thu, Oct 22, 2020 at 01:39:07PM +0300, Topi Miettinen wrote: But I think SELinux has a more complete solution (execmem) which can track the pages better than is possible with seccomp solution which has a very narrow field of view. Maybe this facility

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 22.10.2020 10.54, Szabolcs Nagy wrote: The 10/21/2020 22:44, Jeremy Linton wrote: There is a problem with glibc+systemd on BTI enabled systems. Systemd has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny PROT_EXEC changes. Glibc enables BTI only on segments which are

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 22.10.2020 12.31, Catalin Marinas wrote: On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote: On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote: The dynamic loader has to process the LOAD segments to get to the ELF note that says to enable BTI. Maybe we

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 22.10.2020 11.29, Szabolcs Nagy wrote: The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: On 22.10.2020 10.54, Florian Weimer wrote: * Lennart Poettering: Did you see Topi's comments on the systemd issue? https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 I

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

On 22.10.2020 10.54, Florian Weimer wrote: * Lennart Poettering: On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: Hi, There is a problem with glibc+systemd on BTI enabled systems. Systemd has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny PROT_EXEC

Re: [systemd-devel] Seccomp allow/log action

On 8.7.2020 17.47, Chris PeBenito wrote: I would like to implement a unit option that would make the seccomp action SCMP_ACT_LOG so that I can test SystemCallFilter settings without killing the services, like SELinux permissive mode. I was reading this github issue about seccomp actions from

Re: [systemd-devel] SECLABEL issue into udev

On 10.3.2020 11.59, Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco) wrote: Hi Team, I send this email again because don't receive answer on previous message. I have issue with SECLABEL into systemd udevadm 243 and I see that mainline also have this issue. It look like Yu forgot

Re: [systemd-devel] Failed to determine supported controllers: No such process

On 21.1.2020 18.11, Lennart Poettering wrote: On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote: i was already considering "hidepid" as the root cause systemd-243.5-1.fc31.x86_64 other than systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with hidepid= is broken. We

Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

On 2.1.2020 21.08, Josh Triplett wrote: Lennart Poettering wrote: And noexec doesn't really make much sense for these dirs, as this blocks mmap() with MAP_EXEC and there are plenty apps that want to use that. Moreover "noexec" is at best a protection against accidental execution and not a

Re: [systemd-devel] sd-boot kickstart

On 2.10.2019 9.05, Chris Murphy wrote: On Tue, Oct 1, 2019 at 1:05 AM Damian Ivanov wrote: Hello, I watched the video and presentation https://cfp.all-systems-go.io/media/sdboot-asg2019.pdf I could not agree more! Anaconda/Kickstart install grub as the bootloader. Is there some hidden option

Re: [systemd-devel] keyrings and dbus

On 13.6.2019 20.52, Simon McVittie wrote: On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote: The sessions with slightly different scopes might be useful in some cases. But if this is not the case, would it be possible to unify the scopes and make systemd --user part of the login

Re: [systemd-devel] keyrings and dbus

On 12.6.2019 22.20, Simon McVittie wrote: On Wed, 12 Jun 2019 at 19:57:39 +0300, Andrei Borzenkov wrote: 12.06.2019 19:18, Simon McVittie пишет: systemd user services are not part of a particular login session. They exist outside all login sessions (look at systemd-cgls). gnome-terminal

Re: [systemd-devel] user service not starting on login

On 12.5.2019 18.08, Matt Zagrabelny wrote: Hey Mantas and others, On Thu, May 9, 2019 at 11:57 PM Mantas Mikulėnas > wrote: On Fri, May 10, 2019 at 5:22 AM Matt Zagrabelny mailto:mzagr...@d.umn.edu>> wrote: Greetings, I am attempting to get a

Re: [systemd-devel] systemd-journald.service not using ProtectSystem=strict?

Hello, I have no problems using this with Debian testing: # /etc/systemd/system/systemd-journald.service.d/override.conf [Service] CapabilityBoundingSet=~CAP_MAC_OVERRIDE CAP_SYS_PTRACE InaccessiblePaths=-/dev/pts -/dev/shm -/dev/mqueue -/dev/hugepages -/setuid -/boot -/tmp -/var/tmp -/bin

Re: [systemd-devel] Requirements for successful mounting of RootImage?

Sorry, your messages were in spam folder (must be due to some kind of evil plan by the systemd haters), so I didn't notice them until now. On 07/31/17 13:50, Lennart Poettering wrote: > On So, 30.07.17 13:58, Topi Miettinen (toiwo...@gmail.com) wrote: > >> Hey, >> >>

[systemd-devel] Requirements for successful mounting of RootImage?

Hey, I have this test.service unit: [Unit] [Install] WantedBy=multi-user.target [Service] Type=oneshot ExecStart=/bin/ls -lR RootImage=/fs MountAPIVFS=no The file /fs has a MBR partition table: Disk /dev/loop0: 1.1 MiB, 1192960 bytes, 2330 sectors Units: sectors of 1 * 512 = 512 bytes Sector

Re: [systemd-devel] Any reason why /run and /dev/shm do not have MS_NOEXEC flags set?

On 02/01/17 13:13, Hoyer, Marko (ADITG/SW2) wrote: > Hi, > > thanks to all for your fast feedback. I'll kick off an internal discussion > based on the facts you delivered to find out if our people actually want what > they want ;) Filesystem W^X is a nice idea, but considering scripting or

Re: [systemd-devel] About http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html

On 12/09/16 00:56, Michael Biebl wrote: > Btw, I think we are lacking a good systemd sandboxing howto/tutorial. > The one linked from fdo > (http://0pointer.de/blog/projects/security.html) is pretty dated and > the systemd.exec man page is not coherent enough with regards to > security/sandboxing.

Re: [systemd-devel] deny access to GPU devices

On 11/11/16 20:09, Lennart Poettering wrote: > I have no idea what "slurm" is, but do note that the "devices" cgroup > controller has no future, it is unlikely to ever become available in > cgroupsv2. This is unwelcome news, I think it is a simple and well contained MAC that has been available in

[systemd-devel] Automatic generation of a part of a service unit file

Hello, I made a small systemtap script which can generate a part of configuration for a systemd service. When run, first it produces strace-like output which is annotated with information gathered from various kernel probes. When the process exits, a summary is generated in systemd unit format.

[systemd-devel] Easier alternative to SystemCallFilter

Hello, SystemCallFilter, while a nice feature, is not easy to use because there are hundreds of system calls to be managed. I'm proposing to add a simpler way to prepare seccomp filters (to complement SystemCallFilter), where the user can construct the filter by using predefined system call

Re: [systemd-devel] [PATCH] units: add SecureBits

On 04/24/15 14:52, Lennart Poettering wrote: On Sat, 14.02.15 12:32, Topi Miettinen (toiwo...@gmail.com) wrote: Sorry for the late response, still going through piles of mail. No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit

Re: [systemd-devel] [PATCH/RFC] FuseMAC: user space MAC in systemd

On 03/08/15 23:16, Lennart Poettering wrote: On Mon, 02.03.15 22:49, Topi Miettinen (toiwo...@gmail.com) wrote: Intercept and filter filesystem operations of processes launched by systemd with FUSE. Implement learning, enforcing and auto enforcing/learning modes, enabled with new exec

Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities

On 03/03/15 01:28, Jay Faulkner wrote: Hey, Lennart reviewed this in IRC and suggested I refactor the change in this manner. Now, we have an array of capability:sys call pairs, and iterate through that and then only add the seccomp filter if the capability doesn’t exist. The new patch is

[systemd-devel] [PATCH/RFC] FuseMAC: user space MAC in systemd

+*/ + +/*** + FuseMAC: FUSE-based Mandatory Access Control + Copyright (C) 2015 Topi Miettinen toiwo...@gmail.com + FuseMAC modes: + Learning: add any operations to permitted set + Enforcing: if the operation is not in permitted set, return -EPERM + Auto: like enforcing, but if the file has

Re: [systemd-devel] [PATCH] units: add SecureBits

On 02/11/15 16:32, Lennart Poettering wrote: On Wed, 11.02.15 16:24, Topi Miettinen (toiwo...@gmail.com) wrote: On 02/10/15 21:00, Lennart Poettering wrote: On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits

Re: [systemd-devel] [PATCH] units: add SecureBits

On 02/10/15 21:00, Lennart Poettering wrote: On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's

[systemd-devel] [PATCH v2] units: add SecureBits

No setuid programs are expected to be executed, so add SecureBits=noroot noroot-locked to unit files. --- units/systemd-hostnamed.service.in| 1 + units/systemd-importd.service.in | 1 + units/systemd-journal-gatewayd.service.in | 1 + units/systemd-journal-remote.service.in |

[systemd-devel] [PATCH] units: add SecureBits

No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. --- units/systemd-hostnamed.service.in| 1 + units/systemd-importd.service.in | 1 + units/systemd-journal-gatewayd.service.in | 1 +

Re: [systemd-devel] [PATCH] timesyncd: tighten unit file

On 01/27/15 22:19, Lennart Poettering wrote: On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote: Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS after forking, but before execing systemd-timesyncd, and that binary has an selinux label

Re: [systemd-devel] [PATCH] backlight: let udev properties override clamping

On 01/29/15 00:09, Lennart Poettering wrote: On Wed, 28.01.15 23:51, Topi Miettinen (toiwo...@gmail.com) wrote: diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c index 1271a66..df53b75 100644 --- a/src/backlight/backlight.c +++ b/src/backlight/backlight.c @@ -373,6 +373,7

[systemd-devel] [PATCH] backlight: let udev properties override clamping

On my computer, the minimum brightness enforced by clamping in backlight is too bright. Let udev property ID_BACKLIGHT_CLAMP control whether the brightness is clamped or not. --- man/systemd-backli...@.service.xml | 9 - src/backlight/backlight.c | 5 - 2 files changed, 12

[systemd-devel] [PATCH] backlight: let udev properties override clamping

On my computer, the minimum brightness enforced by clamping in backlight is too bright. Let udev property ID_BACKLIGHT_CLAMP control whether the brightness is clamped or not. --- man/systemd-backli...@.service.xml | 11 ++- src/backlight/backlight.c | 5 - 2 files changed,

Re: [systemd-devel] [PATCH] libudev-monitor: ensure proper string termination

On 01/27/15 00:19, Lennart Poettering wrote: On Sun, 25.01.15 07:10, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/25/15 03:34, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Jan 24, 2015 at 10:39:56AM +0200, Topi Miettinen wrote: Leave space for the terminating zero when reading and make

Re: [systemd-devel] [PATCH] timesyncd: tighten unit file

On 01/27/15 01:54, Lennart Poettering wrote: On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote: There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER. Hmm, that's not true, is it? load_clock_timestamp() is invoked before we drop privs in the daemon. And it certainly

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/26/15 21:04, Lennart Poettering wrote: On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi Miettinen wrote: For example, smartd only needs access to /dev/sd*. Let me spell that differently: smartd only

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/27/15 20:52, Lennart Poettering wrote: On Tue, 27.01.15 18:51, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 21:04, Lennart Poettering wrote: On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/27/15 21:40, Lennart Poettering wrote: On Tue, 27.01.15 21:38, Topi Miettinen (toiwo...@gmail.com) wrote: CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. You should

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/27/15 20:48, Lennart Poettering wrote: On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases

Re: [systemd-devel] [PATCH] timesyncd: tighten unit file

On 01/27/15 21:16, Lennart Poettering wrote: On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 01:54, Lennart Poettering wrote: On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote: There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/27/15 21:35, Lennart Poettering wrote: On Tue, 27.01.15 21:32, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 20:48, Lennart Poettering wrote: On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi Miettinen wrote: For example, smartd only needs access to /dev/sd*. Let me spell that differently: smartd only needs the ability to make arbitrary filesystem changes, defeating any possible configurable security mechanism

Re: [systemd-devel] PrivateDevices with more than basic set of devices?

On 01/26/15 16:13, Lennart Poettering wrote: On Sat, 24.01.15 10:09, Topi Miettinen (toiwo...@gmail.com) wrote: Hello, It would be useful to be able to use PrivateDevices with additional devices to the basic set (null, zero, urandom etc). For example, smartd only needs access to /dev/sd

[systemd-devel] [PATCH] timesyncd: tighten unit file

There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER. No new privileges are needed, especially no setuid fixups are expected. Device policy can be closed, timesyncd does not access any devices. Timesyncd only needs write access to /var/lib/systemd/clock. There's no need to access /boot

Re: [systemd-devel] [PATCH] libudev-monitor: ensure proper string termination

On 01/25/15 03:34, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Jan 24, 2015 at 10:39:56AM +0200, Topi Miettinen wrote: Leave space for the terminating zero when reading and make sure that the last byte is zero. This also makes the check for long packets equivalent to code before 9c89c1ca

[systemd-devel] PrivateDevices with more than basic set of devices?

Hello, It would be useful to be able to use PrivateDevices with additional devices to the basic set (null, zero, urandom etc). For example, smartd only needs access to /dev/sd*. It would be a bit complex to do this without help of systemd, you would have to set up the private /dev filesystem by

[systemd-devel] [PATCH] libudev-monitor: ensure proper string termination

Leave space for the terminating zero when reading and make sure that the last byte is zero. This also makes the check for long packets equivalent to code before 9c89c1ca: reject also packets with size 8192. --- src/libudev/libudev-monitor.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [systemd-devel] [PATCH] libudev: fix check for too long packet

On 01/23/15 17:43, Lennart Poettering wrote: On Fri, 23.01.15 17:29, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/23/15 03:06, Lennart Poettering wrote: On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote: Don't use recvmsg(2) return value to check for too long packets

Re: [systemd-devel] [PATCH] libudev: fix check for too long packet

On 01/23/15 03:06, Lennart Poettering wrote: On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote: Don't use recvmsg(2) return value to check for too long packets (it doesn't work) but MSG_TRUNC flag. Why precisely doesn't this work? I mean, it will consider messages

[systemd-devel] [PATCH v2] backlight: let the administrator override clamping

On my computer, the minimum brightness enforced by clamping in backlight is too bright. Add a new option to override clamping in unit file. While at it, describe the clamping in documentation. --- man/systemd-backli...@.service.xml | 27 +-- src/backlight/backlight.c

[systemd-devel] [PATCH] libudev: fix check for too long packet

Don't use recvmsg(2) return value to check for too long packets (it doesn't work) but MSG_TRUNC flag. --- src/libudev/libudev-monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c index 484fefe..d8e551b 100644

Re: [systemd-devel] Suspicious assertions in resolved

On 01/18/15 20:45, David Herrmann wrote: Hi On Sun, Jan 18, 2015 at 8:12 PM, Topi Miettinen toiwo...@gmail.com wrote: Hello, I think resolved_manager.c function manager_recv() has an assertion that could be triggerable by the server sending an oversized packet: assert

Re: [systemd-devel] Suspicious assertions in resolved

On 01/18/15 21:23, David Herrmann wrote: Hi On Sun, Jan 18, 2015 at 10:15 PM, Topi Miettinen toiwo...@gmail.com wrote: On 01/18/15 20:45, David Herrmann wrote: Hi On Sun, Jan 18, 2015 at 8:12 PM, Topi Miettinen toiwo...@gmail.com wrote: Hello, I think resolved_manager.c function

Re: [systemd-devel] [PATCH] backlight: let the administrator override clamping

On 01/17/15 11:38, David Herrmann wrote: Hi On Sat, Jan 17, 2015 at 12:28 PM, Topi Miettinen toiwo...@gmail.com wrote: On my computer, the minimum brightness enforced by clamping in backlight is too bright. How can 5% of the backlight be too bright? Can you give some information on your

Re: [systemd-devel] [PATCH] backlight: let the administrator override clamping

On 01/17/15 12:34, David Herrmann wrote: Hi On Sat, Jan 17, 2015 at 1:32 PM, Topi Miettinen toiwo...@gmail.com wrote: On 01/17/15 12:19, David Herrmann wrote: Hi On Sat, Jan 17, 2015 at 1:10 PM, Topi Miettinen toiwo...@gmail.com wrote: On 01/17/15 12:03, David Herrmann wrote: Hi On Sat

Re: [systemd-devel] [PATCH] backlight: let the administrator override clamping

On 01/17/15 12:48, David Herrmann wrote: Hi On Sat, Jan 17, 2015 at 1:41 PM, Topi Miettinen toiwo...@gmail.com wrote: On 01/17/15 12:34, David Herrmann wrote: No, we still need clamping! In case your hardware has 256 brightness levels, we really don't want a brightness of 1 as it would

Re: [systemd-devel] [PATCH v3] Do not clear parent mount flags when setting up namespaces

On 01/03/15 12:58, Topi Miettinen wrote: When setting up a namespace, flags like noexec, nosuid and nodev are cleared, so the mounts always have exec, suid, dev flags enabled. Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. Sorry

Re: [systemd-devel] [PATCH v3] Do not clear parent mount flags when setting up namespaces

On 01/04/15 12:00, Djalal Harouni wrote: Hi Topi, On Sun, Jan 04, 2015 at 11:26:12AM +, Topi Miettinen wrote: On 01/03/15 12:58, Topi Miettinen wrote: When setting up a namespace, flags like noexec, nosuid and nodev are cleared, so the mounts always have exec, suid, dev flags enabled

[systemd-devel] [PATCH v4] Do not clear parent mount flags when setting up namespaces

When setting up a namespace, mount flags like noexec, nosuid and nodev are cleared, so the mounts always have exec, suid and dev flags enabled. Copy source directory mount flags to target mount when remounting the bind mounts. --- src/shared/util.c | 23 +-- 1 file changed,

Re: [systemd-devel] [PATCH v2] Do not clear parent mount flags when setting up namespaces

On 01/02/15 23:53, Djalal Harouni wrote: Hi, On Thu, Jan 01, 2015 at 10:36:39PM +0200, Topi Miettinen wrote: Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. As noted by Colin in the other email, there should be a git log message

Re: [systemd-devel] [PATCH v2] Do not clear parent mount flags when setting up namespaces

On 01/02/15 21:49, Colin Walters wrote: On Thu, Jan 1, 2015, at 03:36 PM, Topi Miettinen wrote: Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. I think unless they're obvious, git commits should at least have a brief rationale

[systemd-devel] [PATCH v3] Do not clear parent mount flags when setting up namespaces

When setting up a namespace, flags like noexec, nosuid and nodev are cleared, so the mounts always have exec, suid, dev flags enabled. Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. --- src/core/namespace.c | 12 ++--

[systemd-devel] [PATCH] Do not clear parent mount flags when setting up namespaces

Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. Signed-off-by: Topi Miettinen toiwo...@gmail.com --- src/core/namespace.c | 4 ++-- src/shared/util.c| 20 ++-- src/shared/util.h| 2 ++ 3 files changed, 22

[systemd-devel] [PATCH] Type of mount(2) flags is unsigned long

Signed-off-by: Topi Miettinen toiwo...@gmail.com --- src/core/namespace.c | 2 +- src/core/namespace.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/core/namespace.c b/src/core/namespace.c index 400bc50..19a7590 100644 --- a/src/core/namespace.c +++ b/src/core

Re: [systemd-devel] [PATCH] Do not clear parent mount flags when setting up namespaces

On 01/01/15 14:49, Topi Miettinen wrote: Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. The problem here is that flags noexec, nosuid and nodev are cleared, so the mounts always have exec, suid, dev flags enabled. With the patch

Re: [systemd-devel] [PATCH] Do not clear parent mount flags when setting up namespaces

On 01/01/15 18:08, Dave Reisner wrote: On Thu, Jan 01, 2015 at 04:49:04PM +0200, Topi Miettinen wrote: Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. Signed-off-by: Topi Miettinen toiwo...@gmail.com --- src/core/namespace.c

[systemd-devel] [PATCH v2] Do not clear parent mount flags when setting up namespaces

Copy parent directory mount flags when setting up a namespace and don't accidentally clear mount flags later. --- src/core/namespace.c | 4 ++-- src/shared/util.c| 19 +-- src/shared/util.h| 2 ++ 3 files changed, 21 insertions(+), 4 deletions(-) diff --git