Shell Script -> Benutzer anlegen macOS 13

[FritzS]

Passt dies noch immer so wie in

https://www.apfeltalk.de/community/threads/shell-script-benutzer-anlegen-mac-os-x-10-6.303357/

Muster daraus:

#!/bin/sh

dscl . -create /Users/edv
dscl . -create /Users/edv UserShell /bin/bash
dscl . -create /Users/edv RealName "EDV"
dscl . -create /Users/edv UniqueID "1111" # ändern
dscl . -create /Users/edv PrimaryGroupID 80 # ändern
dscl . -create /Users/edv NFSHomeDirectory /Users/edv

# Passwort setzen
dscl . -passwd /Users/edv passwort

# zum Admin machen
dscl . -append /Groups/admin GroupMembership edv

Ich will aber diesen Benutzer KEIN Passwort geben, er soll sich ja gar nicht anmelden können. Er soll z.B. bei Homebrew als User für einen Daemon - Unbound - dienen. Und es soll eine gleichnamige Gruppe geben.

Muss mal auf einem alten Mac wo MacPorts installiert ist was dort in einigen der von MacPorts angelegten User so alles drinnen steht

dscl . -read /Users/<name>

Kein Passwort - gleich keines setzen oder leer lassen? Manchmal sieht man in Linux/Unix Foren auch das Zeichen * als Passwort.

Nun am alten Mac die von MacPorts angelegten User ausgelesen - was mir dort missfällt, dass bei der ID der gleiche Nummernkreis verwendet wird, den Apple für die Benutzer verwendet, besser wäre hier ab 1000 zu verwenden!

$ dscl . -read /Users/named
dsAttrTypeNative:accountPolicyData:
 <?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>creationTime</key>
    <real>.........</real>
    <key>failedLoginCount</key>
    <integer>0</integer>
    <key>failedLoginTimestamp</key>
    <integer>0</integer>
    <key>passwordLastSetTime</key>
    <real>.........</real>
</dict>
</plist>

AppleMetaNodeLocation: /Local/Default
GeneratedUID: ..........
NFSHomeDirectory: /var/empty
Password: *
PrimaryGroupID: 505
RealName: named
RecordName: named
RecordType: dsRecTypeStandard:Users
UniqueID: 509
UserShell: /usr/bin/false

.....

$ dscl . -read /Users/macports
dsAttrTypeNative:accountPolicyData:
 <?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>creationTime</key>
    <real>...........</real>
</dict>
</plist>

AppleMetaNodeLocation: /Local/Default
GeneratedUID: ............
NFSHomeDirectory: /opt/local/var/macports/home
Password: *
PrimaryGroupID: 501
RealName: MacPorts
RecordName: macports
RecordType: dsRecTypeStandard:Users
UniqueID: 506
UserShell: /usr/bin/false

 

[Marcel Bresink]

Kein Passwort - gleich keines setzen oder leer lassen?

Beides wäre falsch. "Kein Passwort" würde bedeuten, dass der Benutzer sich ohne Kennworteingabe anmelden darf. Das ist genau das Gegenteil von dem was Du willst.

Du musst hier die ungültige Kennwort-Verschlüsselung * einstellen, genau wie es im Beispiel zu sehen ist. * stellt keine gültige Verschlüsselung irgendeines Kennworts dar, mit anderen Worten, dieser Account kann sich niemals anmelden.

Das Beispiel ist im Prinzip immer noch gültig, nur dass man heute standardmäßig "/bin/zsh" in macOS verwendet.

 

[FritzS]

Was der Stern * da bedeutet, wusste ich bisher nicht, danke!
Primary 80 oder gleich auf die gleichnamige Gruppe?

Im Mac Filesystem wird die UniqueID bei Verzeichnissen und Files mit eingetragen, wenn man einen Benutzer löscht findet man diese nun verwaisten Dateien über eine Suche mit der UniqueID. Alles schon durchgemacht!

Wenn man chroot: verwendet soll man das Userverzeichnis dort hinein legen, oder gar keines angeben?

 

[FritzS]

Um eine dazugehörige Gruppe gleichen Namens zu erstellen, das muss man wohl vorher machen.
Aber ist eine zugehörige Gruppe gleichen Namens überhaupt für einen daemon User (z.B. für unbound - per Homebrew installiert) überhaupt notwendig? Falls nicht, in welche Gruppe sollte man den homebrew User geben?
Hintergrund - habe derzeit lokalen DNSSEC BIND named laufen (läuft unter root) - will alternativ unbound testen.
Bei der Installation per Homebrew wird der notwendige user unbound nicht automatisch angelegt.
Darin unterscheidet sich Homebrew von MacPorts!

Warum vergibt man hier der Gruppe ein Passwort?

Create group:

sudo dscl . create /Groups/servsupport

Add some details like real name, password etc.:

sudo dscl . create /Groups/servsupport RealName "Service and Support"
sudo dscl . create /Groups/servsupport passwd "*"
sudo dscl . create /Groups/servsupport gid 799

Use an unused groupID number as gid! You get a sorted list of used gids by entering:

dscl . list /Groups PrimaryGroupID | tr -s ' ' | sort -n -t ' ' -k2,2

Quelle:

Creating a GROUP via Users & Groups in command line

I'd like to script the action of creating a group via Users & Groups and binding it to the admin account and enabling remote login for the same group enabled service and support. I'm vaguely

apple.stackexchange.com

 

[Marcel Bresink]

Aber ist eine zugehörige Gruppe gleichen Namens überhaupt für einen daemon User (z.B. für unbound - per Homebrew installiert) überhaupt notwendig?

Nein.

Falls nicht, in welche Gruppe sollte man den homebrew User geben?

Für den Fall, dass man das nicht weiß, gibt es die Gruppe "nobody" (-2). Man könnte aber auch Standardgruppen wie "daemon" oder "staff" verwenden, je nach dem, welche Rechte die Programme haben sollen.

Warum vergibt man hier der Gruppe ein Passwort?

Das ist ein Pflichteintrag. Aber man vergibt ja gerade kein Passwort, sondern sperrt die Anmeldung.

 

[FritzS]

Welche Rechte hat die Gruppe "daemon" eigentlich?
Was unbound betrifft muss ich mich noch schlau machen und eventuell auf einer Linux/BSD Installation nachsehen. Beim Kompilieren von unbound wurde der User unbound im Programm verankert.

 

[Marcel Bresink]

Welche Rechte hat die Gruppe "daemon" eigentlich?

Die Frage ist falschherum gestellt. Gegeben ist irgendeine Datei oder ein Ordner. Dann kannst Du entscheiden, ob Du der Gruppe daemon ein bestimmtes Zugriffsrecht auf dieses Objekt erteilst.

Üblicherweise hat aber daemon Schreibrecht auf den Ordner /var/run. Der ist, wie der Name andeutet, während des "Laufs" von Hintergrunddiensten zur Ablage von nötigen Daten gedacht, hauptsächlich zur Anzeige, dass ein Dienst läuft, und für Kommunikations-Sockets (Named Pipes).

 

[FritzS]

Erklärt auch diese Zugehörigkeit
Mac - Gruppe: daemon Mitglied: root

Meines Wissens galt (war zumindest früher so), dass daemons mit Ports unter 1024 unter root laufen mussten.
Was natürlich die Sicherheit untergraben konnte.
Habe ich richtig gelesen, dass daemons kurz unter root starten können und dann zu einem nicht so hoch privilegierten user wechseln? Ich finde leider nicht mehr die Quelle dazu.
Oder ist diese Beschränkung für daemons unter Port 1024 mittlerweile in Darwin, BSD, Linux gefallen?