Han_Trio

So gesehen ist ufw auch "nur" ein Frontend für iptables
Ich denke auch, forwarding ist hier das Stichwort, mit dem man sich noch ein wenig näher befassen sollte.
Zum Thema PING: Das dürfte funktionieren, weil es bei ufw eine Sammlung von sog. "before rules" gibt. Die solltest du hier finden:
/etc/ufw/before.rules
Da steht u.a. drin:
# ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT # ok icmp code for FORWARD -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT (zumindest bei mir, aber Mint und Debian sind ja recht nah beieinander)
Diese rules (sofern vorhanden, wovon ich bei dir aber ausgehe) greifen vor sämtlichen manuell konfigurierten Einträgen.
Hier sollten übrigens auch schon die wichtigen "related / established"-Regeln drin stehen, die später für einen sauberen Rückweg von Paketen sorgen:
# quickly process packets for which we already have a connection -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT  

So gesehen ist ufw auch "nur" ein Frontend für iptables
Ich denke auch, forwarding ist hier das Stichwort, mit dem man sich noch ein wenig näher befassen sollte.
Zum Thema PING: Das dürfte funktionieren, weil es bei ufw eine Sammlung von sog. "before rules" gibt. Die solltest du hier finden:
/etc/ufw/before.rules
Da steht u.a. drin:
# ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT # ok icmp code for FORWARD -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT (zumindest bei mir, aber Mint und Debian sind ja recht nah beieinander)
Diese rules (sofern vorhanden, wovon ich bei dir aber ausgehe) greifen vor sämtlichen manuell konfigurierten Einträgen.
Hier sollten übrigens auch schon die wichtigen "related / established"-Regeln drin stehen, die später für einen sauberen Rückweg von Paketen sorgen:
# quickly process packets for which we already have a connection -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT  

"Sonderrechte" ist tatsächlich ein gutes Stichwort in diesem Zusammenhang Das SETGID Bit geht ein bisschen über die "normalen" Dateirechte hinaus. Normalerweise hast du ja die üblichen Rechte: Owner, group + rest, und dann eben jew. read, write + execute.
Es gibt noch drei zusätzliche Mechanismen: SETUID, SETGID und das sog. sticky Bit.
Der Einsatz des SETGID Bits ist zB bei filesharing sinnvoll, wie ja auch in deinem Beispiel.
Wenn du ein Verzeichnis mit aktiviertem / gesetzten SETGID Bit erstellst, welches einer bestimmten Gruppe gehört, dann haben alle Dateien darin automatisch auch diese Gruppenzugehörigkeit (und NICHT, wie normalerweise, die Gruppe des Erstellers).
Das bedeutet, alle User, die eben dieser Gruppe auch angehören, können die Dateien lesen bzw. bearbeiten.
Du musst dann nur noch eine Gruppe finden, die dazu passt - in dem Beispiel sowas wie "Mitarbeiter".
Das SETGID Bit hat ausschließlich mit den Gruppenrechten zu tun, nicht mit Eigentümern, und auch nicht mit "others". Man erkennt es an einem "s" in den Gruppenrechten.
 

Das zentrale Problem scheint ja das hier zu sein:
 
Muss das denn überhaupt in dieser Form gespeichert werden? So wie ich es verstanden habe, könnte man doch auch den output von "who" direkt in grep weiterpipen, so würde als End-output jeweils nur der gesuchte User auftauchen.
Also, dann würde die Info über andere User zwar de facto abgegriffen, aber nirgendwo gespeichert bzw. einsehbar sein.