Benutzerrechte auf Ordner & Dateien?

[X-Worf]

Beim Mounten von Windows-Dateisystemen gibst du explizit den Usernamen, die Gruppe und die Umask mit an.

Das macht die GUI wohl zumindest alles automatisch. Müsste ich mir später mal anschauen. (oder evtl. jetzt schon anlernen...)

Alle Dateien gehören dann temporär diesem einen Nutzer. Entsprechend ist die o.g. Konfiguration der Rechte sinnlos bzw. funktioniert auf diesem Dateisystem nicht. Siehe dazu auch exFAT - Dateiattribute und Sicherheit

Ich meinte eher, wie es sich mit den Zugriffsrechten unter Linux verhält, wenn ich von exFAT oder NTFS-Datenträgern Daten in mein "PAVV"-Verzeichnis kopiere, dass ich ja mit chmod auf 2775 eingestellt habe.

Spoiler: PAVV users 2775

admin@Terra:~$ sudo gpasswd -a drei users
[sudo] Passwort für admin:
Benutzer drei wird zur Gruppe users hinzugefügt.
admin@Terra:~$ sudo gpasswd -a vier  users
Benutzer vier wird zur Gruppe users hinzugefügt.
admin@Terra:~$ id drei
uid=1002(drei) gid=1002(drei) Gruppen=1002(drei),100(users),1004(projekt)
admin@Terra:~$ id vier
uid=1003(vier) gid=1003(vier) Gruppen=1003(vier),100(users),1004(projekt)
admin@Terra:~$ sudo chgrp users /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$ sudo chmod 2775 /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$

Mit Nutzer "drei" hatte ich nun testweise je einen Ordner ("Anleitungen" & "Doku Eingang") von den Datenträgern zu /ProjektAngelegtVonVier kopiert.

ausgelesen mit stat haben die neuen Ordner dort nun aber 2755.

Spoiler: stat

admin@Terra:~$ stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
 Datei: /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
 Größe: 4096            Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 259/7    Inode: 119538097   Verknüpfungen: 3
Zugriff: (2755/drwxr-sr-x)  Uid: ( 1002/    drei)   Gid: (  100/   users)
Kontext: unconfined_u:object_r:unlabeled_t:s0
Zugriff: 2025-02-16 22:15:30.503687341 +0100
Modifiziert: 2019-08-29 22:44:30.000000000 +0200
Geändert: 2025-02-16 22:15:30.494687144 +0100
Geburt: 2025-02-16 22:15:24.866564207 +0100

admin@Terra:~$ stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Doku Eingang
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
stat: der Aufruf von statx für '/ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Doku' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
stat: der Aufruf von statx für 'Eingang' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
admin@Terra:~$

Damit fehlen doch nun aber die Schreibrechte für die Gruppe users, die die Nutzer drei und vier ja eigentlich haben sollten, oder nicht?

Bzw. warum ist das so?
Weil durchs mounten
/run/media/drei/[...]/Doku Eingang
die Rechte schon so gesetzt werden und durchs Kopieren nicht verändert werden?

Müsste ich nun direkt in /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/ mounten, oder irgendwie mit umask arbeiten?

Oder liegt es der GUI/Dolphin und ich sollte die Konsole samt cp nutzen?

Evtl. habe ich aber stat noch nicht richtig bedient/verstanden.
(Erste Anwendung eben und für mich unklare Fehlermeldung:
stat %a /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier/Anleitungen
stat: der Aufruf von statx für '%a' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden)

---

Und offenbar sind Leerzeichen in Ordnern ein Problem für Linux. Das Leerzeichen muss ich dann wohl von Hand ändern, bevor ich Daten fehlerfrei verarbeiten kann.

 

[rgbs]

Und offenbar sind Leerzeichen in Ordnern ein Problem für Linux.

Das ist bullshit.
Und sich mal mit fstab und gio mount zu befassen wäre kein dummer Plan.

Gruß
R.G.

 

[Donnerkind]

Das ist bullshit.

Leider keine sehr hilfreiche Antwort.

Leerzeichen sind natürlich kein Problem. Aber wenn du Wörter in die Shell eintippst, dann trennt diese sie an den Leereichen auf und macht aus jedem Wort ein eigenes Argument. Mit ls Hallo Welt erhält ls den Auftrag, die Dateien Hallo und Welt aufzulisten. Deshalb musst du Dateinamen mit Leerzeichen entweder in Quotes packen, oder die Leerzeichen mit vorangestelltem \ escapen: ls "Hallo Welt". Erstelle mal per GUI eine Datei mit Leerzeichen im Namen und dann geh in die Shell und tippe ls gefolgt von den ersten Buchstaben des Namens und tippe Tab. Die Vervollständigung meiner Bash fügt automatisch die \ ein.

 

[foofoobar]

Das macht die GUI wohl zumindest alles automatisch. Müsste ich mir später mal anschauen. (oder evtl. jetzt schon anlernen...)

uid=value and gid=valueSet the owner and the group of files and directories. The values are numerical. The defaults are the uid and gid of the current process.

https://linux.die.net/man/8/mount.ntfs-3g

Diese Flags werden von fast allen nicht unixoiden Filesystemen unterstützt.

"mount" (ohne weitere Parameter) zeigt auch die Flags aller montierten Filesysteme an.

 

[Pummeluff]

Fakt ist nun mal, dass man bei sudo -i mit root Rechten arbeiten kann ohne dass root aktiviert wurde.

Du kannst genauso

sudo su

verwenden. Und bist dann auch root, auch mit "deaktiviertem" Root-Konto. Das Root-Konto kannst du nicht deaktivieren. Es hat nur kein Passwort und bietet damit keine direkte Loginmöglichkeit.

Deaktivieren könntest du das Konto theoretisch mit eine dieser Methoden. Wäre mal interessant zu testen, wenn du das bei Root macht. Theoretisch sollten sudo -i oder sudo su trotzdem noch funktionieren.

admin@Terra:~$ sudo -i
[sudo] Passwort für admin:
root@Terra:~# "passwort123"

Das ist der Grund, warum ich sudo nicht mag. Im Gegensatz zum Switchuser su brauchst du hier gar kein Passwort. Damit ist der von mir genannte und von rgbs religiös verteidigte Sicherheitsgewinn wieder weg.

Das heißt, das würde passieren, wenn ich bei der Installation "Root deaktivieren" auswähle? Oder ist das wieder ein anderer Zusammenhang? (vgl. #24, Bild2)

Und in Bezug zu #25: Sollte ich bei einer Neuinstallation einfach nur den Benutzer (mit wheel) anlegen, damit die Maske (#24, Bild1) bzgl "Root-Konto" nicht mehr rot ist?

• Gruppe sudo: Der Nutzer darf Befehle mit vorangestelltem sudo ausführen.
• Gruppe wheel: Der Nutzer mit su und Eingabe des Root-Passworts zu Root wechseln.

Deaktivierung des Root-Kontos konfiguriert Dir die 1. Variante. Welche der beiden du nimmst, ist Dir überlassen.

Ich meinte eher, wie es sich mit den Zugriffsrechten unter Linux verhält, wenn ich von exFAT oder NTFS-Datenträgern Daten in mein "PAVV"-Verzeichnis kopiere, dass ich ja mit chmod auf 2775 eingestellt habe.

Die Dateirechte sind immer subtraktiv. Beim Mounten von exFAT-Dateien gibt's beim Mounten eine Defaultmaske. Die dürfte 0022 sein. D.h. von default 0777 (Verzeichnisse) und 0666 (Dateien) wird 0022 abgezogen. Damit kommst du auf 0755 für Verzeichnisse und 0644 für Dateien auf dem Exfat-Dateisystem. Kopierst du dann Dateien rüber auf Dein Shared-Verzeichnis mit 2775 wird das "logische Und" berechnet. D.h. 664 & 644 = 644 für Dateien und 2775 & 0755 = 0755 für Verzeichnisse.

 

[foofoobar]

Die Dateirechte sind immer subtraktiv. Beim Mounten von exFAT-Dateien gibt's beim Mounten eine Defaultmaske. Die dürfte 0022 sein. D.h. von default 0777 (Verzeichnisse) und 0666 (Dateien) wird 0022 abgezogen. Damit kommst du auf 0755 für Verzeichnisse und 0644 für Dateien auf dem Exfat-Dateisystem. Kopierst du dann Dateien rüber auf Dein Shared-Verzeichnis mit 2775 wird das "logische Und" berechnet. D.h. 664 & 644 = 644 für Dateien und 2775 & 0755 = 0755 für Verzeichnisse.

umask=value Set the umask (the bitmask of the permissions that are not present, in octal). The default is the umask of the current process.
dmask=value Set the umask for directories only.
fmask=value Set the umask for files only.
uid=n Set the owner for all files and directories. The default is the owner of the current process.
gid=n Set the group for all files and directories. The default is the group of the current process.

https://manpages.debian.org/jessie/exfat-fuse/mount.exfat.8.en.html

Und mit "mount" ohne Parameter kann man sich die aktiven flags anzeigen lassen.

 

[rgbs]

• Gruppe sudo: Der Nutzer darf Befehle mit vorangestelltem sudo ausführen.
• Gruppe wheel: Der Nutzer mit su und Eingabe des Root-Passworts zu Root wechseln.

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/':
"Stattdessen wird der Standardbenutzer zur Gruppe 'wheel' hinzugefügt. Mitglieder dieser Gruppe können mit dem Befehl 'sudo' Root-Rechte erhalten."

Gruß
R.G.

 

[rgbs]

Das Root-Konto kannst du nicht deaktivieren.

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/:
"Aus Sicherheitsgründen ist das root-Konto auf Fedora Workstations standardmäßig deaktiviert."
Aber es ist schon klar, Du hast mehr Ahnung als die Leute von Redhat.
Und mal so am Rande, die Gruppe sudo gibt es bei der Standard Installation von Fedora nicht.
Ich jedenfalls halte mich an die sicherheitstechnischen Vorgaben des Erstellers der Distribution, bei mir Ubuntu und da ist das Administratorkonto ebenfalls deaktiviert (das hat mit Religion nichts zu tun, sondern mit Vernunft).

Gruß
R.G.

 

[foofoobar]

Aus https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/:
"Aus Sicherheitsgründen ist das root-Konto auf Fedora Workstations standardmäßig deaktiviert."
Aber es ist schon klar, Du hast mehr Ahnung als die Leute von Redhat.
Und mal so am Rande, die Gruppe sudo gibt es bei der Standard Installation von Fedora nicht.
Ich jedenfalls halte mich an die sicherheitstechnischen Vorgaben des Erstellers der Distribution, bei mir Ubuntu und da ist das Administratorkonto ebenfalls deaktiviert (das hat mit Religion nichts zu tun, sondern mit Vernunft).

Das ist eine vereinfache Formulierung die eine Zielgruppe adressiert welche sich mit dem Thema nicht so gut auskennt.

 

[rgbs]

Das ist eine vereinfache Formulierung

Ich zähle jetzt auch mal Erbsen, eine "vereinfache Formulierung" gibt es nicht.

Gruß
R.G.

 

[rgbs]

Aus #45 von @Pummeluff

Auch falsch, man muss das Passwort des users eingeben. (ich spare mir jetzt, den getting-started-guide nochmal zu verlinken).

Gruß
R.G.

 

[foofoobar]

Das ist der Grund, warum ich sudo nicht mag. Im Gegensatz zum Switchuser su brauchst du hier gar kein Passwort. Damit ist der von mir genannte und von rgbs religiös verteidigte Sicherheitsgewinn wieder weg.

Das kann man konfigurieren:

NOPASSWD and PASSWD

By default, sudo requires that a user authenticate him or herself before running a command. This behavior can be modified via the NOPASSWD tag.

timestamp_timeout
Number of minutes that can elapse before sudo will ask for a passwd again. The timeout may include a fractional component if minute granularity isinsufficient, for example 2.5. The default is 5. Set this to 0 to always prompt for a password. If set to a value less than 0 the user's time stamp will neverexpire. This can be used to allow users to create or delete their own time stamps via ''sudo -v'' and ''sudo -k'' respectively.

https://linux.die.net/man/5/sudoers

 

[GrillSgt]

Das Root-Konto kannst du nicht deaktivieren. Es hat nur kein Passwort und bietet damit keine direkte Loginmöglichkeit.

Das ist technisch gesehen nicht korrekt und nicht ganz falsch.
Das Passwort des Kontos ist gesperrt was faktisch einem deaktivierten Konto gleichkommt. Zu erkennen am Ausrufezeichen anstelle eines "x" Eintrag in der /etc/shadow Datei:

root:!:!1975...

Alternativ könnte man das "x" in der /etc/passwd auch durch ein "!" ersetzen. Das wäre ein deaktivieren des Kontos.
Nachgesehen ist das auf Ubuntu. Bei Fedora müsste es ggfls.. jmd. prüfen. Würde kein sudo verwendet werden bzw. die sudoers Liste ist nicht korrekt konfiguriert wäre ein Aussperren aus dem System so möglich.

Deaktivieren könntest du das Konto theoretisch mit eine dieser Methoden. Wäre mal interessant zu testen, wenn du das bei Root macht. Theoretisch sollten sudo -i oder sudo su trotzdem noch funktionieren.

Ändert nichts. sudo -i bzw. sudo su funktionieren weiterhin.

 

[foofoobar]

Alternativ könnte man das "x" in der /etc/passwd auch durch ein "!" ersetzen. Das wäre ein deaktivieren des Kontos.
Nachgesehen ist das auf Ubuntu. Bei Fedora müsste es ggfls.. jmd. prüfen. Würde kein sudo verwendet werden bzw. die sudoers Liste ist nicht korrekt konfiguriert wäre ein Aussperren aus dem System so möglich.

RTFM hilft: https://www.computerbase.de/forum/t...f-ordner-dateien.2229709/page-2#post-30300111