Festlegen von Berechtigungen für Netzwerkschnittstellen

Bei jedem Neustart werden die Berechtigungen auf den Netzwerkgeräten /dev/bpf*geändert.

Als Entwickler möchte ich Zugriff auf diese Dateien schreiben. Dies kann leicht mit einem behoben werdenchmod .

Was ist die eleganteste Lösung, um dieses Problem dauerhaft zu beheben?

macos permission

— rds
quelle

Wireshark StartupItemliefert ein , das genau das tut; Die StartupItems-API ist jedoch veraltet:

 The SystemStarter utility is deprecated.  System services should instead
 be described by a launchd.plist(5).  See launchd(8) for more details.
 The launchd utility is available on Mac OS X 10.4 and later.

 In earlier versions of Mac OS X, the SystemStarter utility is used to
 start, stop, and restart the system services which are described in the
 /Library/StartupItems/ and /System/Library/StartupItems/ paths.

Da Sie also nach der "elegantesten Lösung" fragen, wäre das ein Launch-Daemon.

Ich habe den folgenden Code nicht ausprobiert, aber er sollte ungefähr korrekt sein.

Erstellen Sie eine Datei /Library/LaunchDaemons/com.stackexchange.apple.bpf-helper.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.stackexchange.apple.bpf-helper</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/PrivilegedHelperTools/com.stackexchange.apple.bpf-helper.sh</string>
    </array>
</dict>
</plist>

Und eine Datei /Library/PrivilegedHelperTools/com.stackexchange.apple.bpf-helper.sh:

#!/bin/sh
chgrp admin /dev/bpf*
chmod g+rw /dev/bpf*

Beide sollten im Besitz von sein root:wheel. Der erste sollte 644 sein; Die zweite 755 (600 bzw. 700) wird wahrscheinlich ebenfalls funktionieren.

Sie können launchctl load -w /Library/LaunchDaemons/com.stackexchange.apple.bpf-helper.plistes versuchen, ohne einen Neustart.

— Sören Kuklau
quelle

[launchd-dev] Über den ServiceIPC-Schlüssel :

On Leopard and later, you can treat the ServiceIPC key as   being inferred through the presence of a Sockets or MachServices   dictionary. There's no need to explicitly specify it.

— Lri

Hatte eigentlich nicht vorgehabt, das hier zu belassen, da es eigentlich irrelevant sein sollte, aber danke. :)

— Sören Kuklau