Re: systemd CAP_DAC_READ_SEARCH

Konrad Rosenbaum <[email protected]>
Newsgroups gmane.user-groups.linux.dresden
Message-ID <[email protected]>
Hi,

On 28/06/2023 22:28, Andreas Fett wrote:
> On Wed, Jun 28, 2023 at 10:02:37PM +0200, Christian Perle wrote:
>
>> Die Capability CAP_DAC_READ_SEARCH erlaubt zwar open()/openat()
>> auf eine sonst nicht lesbare Datei, aber die access()-Familie liefert
>> einen Fehler. Ob das jetzt inkonsistentes Verhalten des Kernels
>> ist, sei mal dahingestellt.
> Ich finde dieses access()/open() Pattern im userspace ist generell
> kaputt. Das ist ja eh immer anfällig für race conditions.

Die access() calls ignorieren zum Teil auch Flags auf Mount-Ebene, ACLs, 
Superuser-Rechte etc. Es werden nur stupide die Bits der klassischen 
Zugriffsrechte geprüft. Es gibt Race Conditions, Security Considerations 
und angeblich auch versteckte Drachen, die Hunger auf ahnungslose 
Programmierer haben.

Die man-Page klingt nicht gerade wie eine uneingeschränkte Empfehlung 
durch die Kernelentwickler.

Kurz: man kann nur davon abraten access() zu benutzen.


     Konrad
OpenPGP_0xBE96A6EE776FE5D0.asc (application/pgp-keys, 2.1 KB)
-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBGQTN1ABCAC7kQZS2TU9qt/4ws8heReMiMzjslrUukVWbdUWZq2Ech3FXx13
fzAInil/7JxRSEOSA053tYJTIuNHAUfu+F6zoS5zStJwlneMKdBP8Z5Ip84uMKiB
ER8DapARKwfFYR223Stf0OIA+8rgMwzgHRvyZagLVwOv7LielMmmG5jVWTXQe+W8
DBU3bgPQsDOwbzPbmENPdsKQuURlxIVzpdcy1HYgA/n7BMggKhBmnirJRegrQkS/
EiEHlgXg+Z+SRomaPgQ9DEJpyVpkjD3QktHsS/IzN4Sf7yPhx+yHUFJRW7BH+R4O
yRaqghjyThLnhqWfUys4AJyeFr5rlfFeFGNRABEBAAHNI0tvbnJhZCBSb3NlbmJh
dW0gPGtvbnJhZEBzaWxtb3IuZGU+wsCUBBMBCAA+FiEEzYnTjdyZRcKtxb1kvpam
7ndv5dAFAmQTN1ACGy8FCRLMAwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ
vpam7ndv5dCcWQf9GxTvVpZX1TZLLlvwr7pIgp84vE8ykBrS/9nLG/jOrN8J+vln
qO0WFeVqIFdpBPhmPhinRiULbNbzSfGfO9LHR3A9Uitfe17XeUyODM3X8AP+gB0J
wRjMR4B5vF6iJDkg/b3MzQjxZSHArSqkIMrIu6FRpN3GuesR0Xg4vncmw87a3cvt
NbeUzj5hkALgmrWhgwOEDr7kOyfuCzm/olGtseDLdFRFOVQSVZF5Z4xNrKf3NjrG
15EbBV+V1ev6tfjrx8t8KXHD2T3rWeRCxfnaTtrU516BX+OcQZMjRYHdNLJrmbsy
rFJAxIs9vbulJVGv7t9+EvJrzK0flAJh12FXcc7ATQRkEzdQAQgA26ArSm5Yek87
c5Slyjml1OhinWOjGrFOllkMrKTfPlDHF41n2bnX9ZyXuauakXX6RD+vLAJPk+LK
wvkO5Jbf7usmX3jxW/z6VfcosImrEjjsT4bdw4MftKojc2ojDIXjTgMy/9oSEdK+
3Op1+uknw4GaXLuXTkZ7A7pgIK3jf1v5D+oEjDjbk4sK546DCAwVKgEek2DP4bw0
WgeghWdGGhCo9xqk3LVQzNEGBZ29K8/rWlD3qa6bwmpxLPY9C9t8VTJCfboOXLgc
T9Hmq/f1ufKzgmPfpmm7sGp5ugmCkY6J8ALATDwqvWUhlFOU68zQMVqRTYu1sQ7N
ULffSDI+xQARAQABwsGyBBgBCAAmFiEEzYnTjdyZRcKtxb1kvpam7ndv5dAFAmQT
N1ACGy4FCRLMAwABQAkQvpam7ndv5dDAdCAEGQEIAB0WIQSOQLTnoiFwolgmvwbF
TgWuuTp+dQUCZBM3UAAKCRDFTgWuuTp+dRGoB/92KjoVj3dlLMmB7HYH2zF9Db3+
Th28RMqMiU14d2BpBa9bPI7DTd2YRhiwREf3V3OcCHezzJcxh8rG7dOrXHYyzoWZ
H4/qFAQ+lEFf8CwMPs3YeZ4+HZRTgPwtcDtYhtbPQiyzQVPiL36GF1thmnGxAQTB
5sPk4CM/nByL9cKCa7ts/oTGhAdYVPcMlzW27/LtXWt5BHdqISCI5GySBbzYFlSn
qiBEJZghJFl3Bld4kBOH1ZaBBhNMg+tPB/aXEiLO/OtEv7CvDhMMzsfHjrbG0mkB
gNwRYarnrC3OaOBvrhkBq7Ab00NUvxsdxi9JiZ3EnPob5XLzIj0lwca8o4A17G8I
AIWEoz9cn4oksP6F8lcAnyFIpNRujw1EE/CROKxwfUnZ2ZedkN73Bb/7Vr7Pyo8O
IiuyYWJJVhy2TI84t36jKkU+YgfS7nkoHD1mHtS0ksx0xLNzPCGskiEdOaeZ6Y4E
oIWLHY8gzddbB2umkKM0ffbINkwNy5lysGvA/IrLirKBi8rv1GF9oDq6VoCdRvof
jipRVkM5CPZoOOyCJJDGxSOq8R8POcWPLodu4mGGTW1YteNJeCkLQbHBfozwpVwu
IZj3joU3DmMLiyDv1dYPs9J9aPnYZOSdWW4NjYWkssB/ejO1EDPaH6sTBhsYhO8U
6g6AJp8abjwFklwKQ3WssHE=
=tst6
-----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature (application/pgp-signature, 495 B) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.