Change the default udev rule for /dev/ptp* from 0660 to 0664,
allowing unprivileged users read-only access.
NIC telemetry and hardware logs often use device timestamps that must
be correlated with host time via read-only PTP ioctls (e.g.
cross-timestamp queries). Requiring privileged access makes these
workflows unnecessarily restrictive.
Older kernels lacked proper permission checks in some PTP ioctls.
Kernel commit b4e53b15c04e3852949003752f48f7a14ae39e86 ("ptp: Add PHC
file mode checks. Allow RO adjtime() without FMODE_WRITE.") introduces
the necessary file mode validation, ensuring that read access does not
permit clock modification or configuration changes, which still require
write permissions.
This commit has been backported to all actively maintained stable
kernel branches.
Related to #31034
In 5c05a339c6 I retroactively changed the NEWS
entry for v259. But this is very confusing, because it looks like the original
change never happened and it's not clear what is being reverted.
Let's restore the original text, and just add a short note, but then move
the new text to the section for v260.
Actually GNOME sets a clamp of 1% and divides in 20 steps the brightness
control. Using 5% clamp makes things like in a device with max value 640
to always be in the first brightness step in GNOME and we can't leave in
the minimum.
GNOME set steps of 640/20 = 32 with the zero step 640 * 1% = 6. When we
restart the device with the lowest bright systemd sees 6 but sets
640 * 5% = 32, so we get the brightness in the first step.
Tests in IPS and OLED panels have been done and 1% still seems a
comprensive minimun usable value so use that to allow all environments
to be able to set lower brightness values that won't be raised by
systemd at boot.
If your user enviroment allow to set excesive lower unusable values you
should blame it or yourself if you directle changes it through sysfs but
not systemd.
This reverts (in spirit) "network/tuntap: deny from owning Tun/Tap interfaces",
commit 940441b44c.
Justification similar as in the previous commit. The check is only
partially connected to the intended purpose and breaks backwards compat
without a sufficient reason.
Alternative fix for #37279.
This reverts (in sprit) commit f5cdf9515a,
"udev-rules: ignore non-system user/group in OWNER=/GROUP=".
The original change was done to clean up a situation where we added a
new group, but the group could already have been used for some other
purposes, and now the some unexpected entity would own the device.
Unfortunately, this check doesn't really address the issue, since the
existing account might as well be a system account, which might be
equally bad. In addition, this change is a big compatiblity break,
causing existing rules to stop working. Since quite a lot of systems
have local configuration to assign devices to users for various
purposes, this is very noticable to users. In a way, the original change
to add a new group was the compat break, and follow-up patch to cahnge
the rule parsing evolved a small compat break into a much bigger one.
There is merit to the change though, since device nodes shouldn't be
owned by users and groups and different mechanisms should be used
instead. To avoid breaking users systems, and since the original goal
cannot be achieved by this patch, let's downgrade this to a warning
to guide users towards different solutions.
The current tree doesn't even compile with libidn(1) after
2c7bdaf9f1, which included
a non-existent call to check_dlopen_blocked() somehow.
Hence, it feels safe to just nuke legacy support from
our repo.
I think we should make it clear that the "incomplete musl support" does not
mean that it'll for certain be completed later. The feedback from users will be
an important consideration.
Yu Watanabe
Carolina Jubran
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Mike Yuan
Jörg Behrmann
David Santamaría Rogado
Peter Oliver
Peter Oliver
Zbigniew Jędrzejewski-Szmek
Armin Brauns
Luca Boccassi
Lennart Poettering