Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #110870 > unrolled thread

Formatierung des Datenbereiches fuer Dual-Boot System

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-09 12:41 -0700
    Re: Formatierung des Datenbereiches fuer Dual-Boot System Kay Martinen <kay@martinen.de> - 2020-06-09 22:39 +0200
      Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-09 14:10 -0700
        Re: Formatierung des Datenbereiches fuer Dual-Boot System Kay Martinen <kay@martinen.de> - 2020-06-10 02:56 +0200
          Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-12 14:40 -0700
            Re: Formatierung des Datenbereiches fuer Dual-Boot System Kay Martinen <kay@martinen.de> - 2020-06-13 00:29 +0200
              Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-13 11:27 -0700
                Re: Formatierung des Datenbereiches fuer Dual-Boot System Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-14 15:03 +0200
                  Re: Formatierung des Datenbereiches fuer Dual-Boot System Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-15 13:22 +0200
                    Re: Formatierung des Datenbereiches fuer Dual-Boot System Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-16 00:09 +0200
                      Re: Formatierung des Datenbereiches fuer Dual-Boot System Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-16 08:51 +0200
                        Re: Formatierung des Datenbereiches fuer Dual-Boot System Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-16 10:22 +0200
                          Re: Formatierung des Datenbereiches fuer Dual-Boot System Gert Link <gertlink_nospam@gmx.de> - 2020-06-16 10:54 +0200
                          Re: Formatierung des Datenbereiches fuer Dual-Boot System Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-16 15:30 +0200
                        Re: Formatierung des Datenbereiches fuer Dual-Boot System Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2020-07-12 16:09 +0200
                    Re: Formatierung des Datenbereiches fuer Dual-Boot System Christian Garbs <mitch@cgarbs.de> - 2020-06-16 09:10 +0200
                      Re: Formatierung des Datenbereiches fuer Dual-Boot System Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-16 09:32 +0200
                        Re: Formatierung des Datenbereiches fuer Dual-Boot System Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-16 21:54 +0200
                        Re: Formatierung des Datenbereiches fuer Dual-Boot System Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-06-16 22:42 +0200
                        Re: Formatierung des Datenbereiches fuer Dual-Boot System Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-17 07:24 +0200
                  Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-15 14:44 -0700
    Re: Formatierung des Datenbereiches fuer Dual-Boot System Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-06-10 08:37 +0200
      Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-12 14:43 -0700
    Re: Formatierung des Datenbereiches fuer Dual-Boot System Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-10 09:30 +0200
      Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-12 14:47 -0700
        Re: Formatierung des Datenbereiches fuer Dual-Boot System Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-13 08:36 +0200
          Re: Formatierung des Datenbereiches fuer Dual-Boot System Herrand Petrowitsch <herrands@t-online.de> - 2020-06-13 13:36 +0200
            Re: Formatierung des Datenbereiches fuer Dual-Boot System Herrand Petrowitsch <herrands@t-online.de> - 2020-06-13 14:25 +0200
            Re: Formatierung des Datenbereiches fuer Dual-Boot System Herrand Petrowitsch <herrands@t-online.de> - 2020-06-13 14:27 +0200
          Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-13 11:30 -0700
    Re: Formatierung des Datenbereiches fuer Dual-Boot System Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-10 10:14 +0200
      Re: Formatierung des Datenbereiches fuer Dual-Boot System Joerg <news@analogconsultants.com> - 2020-06-12 15:05 -0700

Page 1 of 2  [1] 2  Next page →

#110870 — Formatierung des Datenbereiches fuer Dual-Boot System

Aus verschiedenen Gruenden muss bei drei Rechnern Dual-Boot bleiben, 
geht wirklich nicht mit VM. In meinem Fall ist das MX-Linux 19 auf ext4 
File System und Windows 7 Professional auf NTFS. Beide OS sollen 
langfristig Schreib- und Lesezugang zu demselben Datenbereich 
(Partition) innerhalb des jeweiligen Rechners haben. Weiterhin soll 
dieser Datenbereich per Unison staendig mit einem gleich aussehenden 
Datenbereich auf einem NAS synchronisiert werden, was aber nur von Linux 
aus gemacht wuerde. Sync von Windows aus ist nicht noetig, weil nicht 
mehr oft als OS benutzt. Auf dem NAS ist derzeit alles ext3 und es 
kommuniziert mit allen anderen Rechnern, egal in welchem Boot, per Samba.

Mit DiskGenius oder aehnlichem koennte Windows vielleicht auf eine ext4 
Partition zugreifen, aber ich habe Bedenken, dass mir das eines Tages um 
die Ohren fliegt. Sieht also wohl nach NTFS aus. Das wiederum soll 
zicken, weil Dateiattribute zwischen NTFS und ext3 nicht kompatibel 
sind, symlinks und so weiter.

https://www.howtogeek.com/howto/35807/how-to-harmonize-your-dual-boot-setup-for-windows-and-ubuntu/

Ehe ich mich als Linx-Anfaenger in die Nesseln setze, hat jemand eine 
Idee oder sieht ein gravierendes Problem?

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [next] | [standalone]

#110871

Am 09.06.20 um 21:41 schrieb Joerg:
> Aus verschiedenen Gruenden muss bei drei Rechnern Dual-Boot bleiben,
> geht wirklich nicht mit VM. In meinem Fall ist das MX-Linux 19 auf ext4
> File System und Windows 7 Professional auf NTFS. Beide OS sollen
> langfristig Schreib- und Lesezugang zu demselben Datenbereich
> (Partition) innerhalb des jeweiligen Rechners haben. Weiterhin soll

Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows und
Linux anlegen und diese in beiden OS einklinken. Windows macht es
automatisch z.b. auf D: und bei Linux hilft ein Mountpoint den du selbst
festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem weil
das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen zum
NAS. Damit meinst du vermutlich deine PogoPlug-Teile.

Ist meine Ansicht, auch wenn ich das so noch nicht selbst machte.
Jedenfalls nicht dauerhaft.

Kay

-- 
Posted via SN

[toc] | [prev] | [next] | [standalone]

#110872

On 2020-06-09 13:39, Kay Martinen wrote:
> Am 09.06.20 um 21:41 schrieb Joerg:
>> Aus verschiedenen Gruenden muss bei drei Rechnern Dual-Boot bleiben,
>> geht wirklich nicht mit VM. In meinem Fall ist das MX-Linux 19 auf ext4
>> File System und Windows 7 Professional auf NTFS. Beide OS sollen
>> langfristig Schreib- und Lesezugang zu demselben Datenbereich
>> (Partition) innerhalb des jeweiligen Rechners haben. Weiterhin soll
>
> Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows und
> Linux anlegen und diese in beiden OS einklinken. Windows macht es
> automatisch z.b. auf D: und bei Linux hilft ein Mountpoint den du selbst
> festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem weil
> das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen zum
> NAS. Damit meinst du vermutlich deine PogoPlug-Teile.
>
> Ist meine Ansicht, auch wenn ich das so noch nicht selbst machte.
> Jedenfalls nicht dauerhaft.
>

Danke. Das mit den Berechtigungen ist schon einigermassen wichtig, da 
auch auf dem NAS liegend. Es gibt Verzeichnisse, wo alle dran duerfen 
und dann welche, wo nur ich selbst ran darf, oder die Familie.

Die Berechtigungen sind natuerlich auch nochmal in der smb.conf des NAS 
festgelegt. Da dies bei Samba mit Unterverzeichnissen unhandlich wird, 
muesste ich den Datensatz in drei Teile zerlegen (nur ich, Familie, 
alle) und jeden Teil einzeln als Samba Share rausgeben. Ist machbar. 
Reicht das prinzipiell?

Auf den Rechnern selbst ist es weniger wichtig, da die betreffenden 
Rechner nur von mir benutzt werden und Password-Schutz haben. Aber nach 
Sync von der FAT32 Partition aus gaebe es dann, so wie ich es verstehe, 
fuer die betreffenden Files wegen Ueberschreibens keine 
Zugriffsbeschraenkungen mehr auf der ext3 Partition des NAS.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110881

Am 09.06.20 um 23:10 schrieb Joerg:
> On 2020-06-09 13:39, Kay Martinen wrote:
>> Am 09.06.20 um 21:41 schrieb Joerg:
>>> Aus verschiedenen Gruenden muss bei drei Rechnern Dual-Boot bleiben,
>>> geht wirklich nicht mit VM. In meinem Fall ist das MX-Linux 19 auf ext4
>>> File System und Windows 7 Professional auf NTFS. Beide OS sollen
>>> langfristig Schreib- und Lesezugang zu demselben Datenbereich
>>> (Partition) innerhalb des jeweiligen Rechners haben. Weiterhin soll
>>
>> Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows und
>> Linux anlegen und diese in beiden OS einklinken. Windows macht es
>> automatisch z.b. auf D: und bei Linux hilft ein Mountpoint den du selbst
>> festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem weil
>> das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen zum
>> NAS. Damit meinst du vermutlich deine PogoPlug-Teile.
>>
>> Ist meine Ansicht, auch wenn ich das so noch nicht selbst machte.
>> Jedenfalls nicht dauerhaft.
>>
> 
> Danke. Das mit den Berechtigungen ist schon einigermassen wichtig, da
> auch auf dem NAS liegend. Es gibt Verzeichnisse, wo alle dran duerfen
> und dann welche, wo nur ich selbst ran darf, oder die Familie.

Das müßte eigentlich; auch in einem einzigen Share; mit den linux
benutzer/gruppenrechten gehen. Du selbst als Owner, deine Familie z.b.
als Gruppe "Family" und alle anderen als gäste oder "others".

Problem ist dann wohl eher wenn du von Windows aus auf das Share
schreiben wolltest die richtigen Berechtigungen zu setzen. Von Linux aus
kannst du die leichter einstellen (z.B. per nfs statt samba). Du weißt
das die Dateirechte (seiner für ihn lokalen Dateien) von samba
berücksichtigt werden oder?

Ein 0777 als zugriffsrechte gäbe alles für alle zum lesen, schreiben,
Ausführen/durchsuchen frei. Ein 0700 nur für dich als owner, 0770 dann
für dich und die Familie und die weiteren Abstufungen für RWX darfst du
gern selbst in den man pages nach schlagen.

> Die Berechtigungen sind natuerlich auch nochmal in der smb.conf des NAS
> festgelegt. Da dies bei Samba mit Unterverzeichnissen unhandlich wird,
> muesste ich den Datensatz in drei Teile zerlegen (nur ich, Familie,
> alle) und jeden Teil einzeln als Samba Share rausgeben. Ist machbar.
> Reicht das prinzipiell?

Schon richtig. Für jede Gruppe ein Share ein zu richten ist dann
einfacher. Dann kann man dem Samba z.b. auch sagen welcher user lese und
schreib zugriff haben darf. FYI hier:

https://www.samba.org/samba/docs/using_samba/ch08.html

Wenn du also die benutzer joerg, frau, kind (o.ä.) im Linux und in Samba
als Benutzer hättest und dazu eine benutzergruppe Family der all diese
Benutzer zugeordnet sind dann kannst du z.b. dein Homedir oder ein
weiteres share für deine eigenen Dateien nehmen. Dann ein [family] share
das der gruppe family zugeordnet ist und ein [public] share das alle
ohne schutz benutzen dürften.

Beim Family Share muß das verzeichnis hinter dem share auf dem NAS aber
auch für diese gruppe schreibrechte haben.

> Auf den Rechnern selbst ist es weniger wichtig, da die betreffenden
> Rechner nur von mir benutzt werden und Password-Schutz haben. Aber nach
> Sync von der FAT32 Partition aus gaebe es dann, so wie ich es verstehe,
> fuer die betreffenden Files wegen Ueberschreibens keine
> Zugriffsbeschraenkungen mehr auf der ext3 Partition des NAS.

Wenn du ein Share hast das nur du beschreiben darfst und von der FAT
Datenpartition dort *nur* Dateien rein schiebst die du lesen/schreiben
darfst dann werden die dort auch so gespeichert werden. Wenn das share
so eingerichtet ist. Denn samba setzt für neue Files und Directorys die
Berechtigungen auf dem Zieldateisystem (bei dir ext3) so wie du es ihm
vorgibst. Ebenso kannst du dann mit einem Familien-share verfahren und
mit dem das alle anderen nutzen dürfen. Public=yes kannst du bei
letzterem z.b. setzen damit alle ohne schutz drauf zugreifen dürften.

Du mußt evtl. noch die Umsetzung der DOS Attribute auf die
linux-dateirechte beachten oder umkonfigurieren. Aber wenn es nur
datendateien sind die kein hidden oder system attribut brauchen, dürfte
das keine Probleme machen.

Wenn auf die freigabe [joerg] nur der samba- und system-user joerg
zugreifen darf, auf die freigabe [family] nur die Mitglieder der Gruppe
family (inkl. dir selbst) und auf die Freigabe [public] alle dann sollte
das schon so reichen. Meine ich, der ich dabei nun auch kein Echter
Experte bin.

Uff. Eigentlich wollte ich nicht so viel schreiben. Hoffe es hilft.

Kay

-- 
Posted via SN

[toc] | [prev] | [next] | [standalone]

#110987

On 2020-06-09 17:56, Kay Martinen wrote:
> Am 09.06.20 um 23:10 schrieb Joerg:
>> On 2020-06-09 13:39, Kay Martinen wrote:
>>> Am 09.06.20 um 21:41 schrieb Joerg:
>>>> Aus verschiedenen Gruenden muss bei drei Rechnern Dual-Boot bleiben,
>>>> geht wirklich nicht mit VM. In meinem Fall ist das MX-Linux 19 auf ext4
>>>> File System und Windows 7 Professional auf NTFS. Beide OS sollen
>>>> langfristig Schreib- und Lesezugang zu demselben Datenbereich
>>>> (Partition) innerhalb des jeweiligen Rechners haben. Weiterhin soll
>>>
>>> Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows und
>>> Linux anlegen und diese in beiden OS einklinken. Windows macht es
>>> automatisch z.b. auf D: und bei Linux hilft ein Mountpoint den du selbst
>>> festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem weil
>>> das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen zum
>>> NAS. Damit meinst du vermutlich deine PogoPlug-Teile.
>>>
>>> Ist meine Ansicht, auch wenn ich das so noch nicht selbst machte.
>>> Jedenfalls nicht dauerhaft.
>>>
>>
>> Danke. Das mit den Berechtigungen ist schon einigermassen wichtig, da
>> auch auf dem NAS liegend. Es gibt Verzeichnisse, wo alle dran duerfen
>> und dann welche, wo nur ich selbst ran darf, oder die Familie.
>
> Das müßte eigentlich; auch in einem einzigen Share; mit den linux
> benutzer/gruppenrechten gehen. Du selbst als Owner, deine Familie z.b.
> als Gruppe "Family" und alle anderen als gäste oder "others".
>
> Problem ist dann wohl eher wenn du von Windows aus auf das Share
> schreiben wolltest die richtigen Berechtigungen zu setzen. Von Linux aus
> kannst du die leichter einstellen (z.B. per nfs statt samba). Du weißt
> das die Dateirechte (seiner für ihn lokalen Dateien) von samba
> berücksichtigt werden oder?
>

Ja, aber es gibt irgendeine "AND" Verknuepfung. Wenn ein File oder ein 
Verzeichnis weniger Rechte zuweist als Samba, dann werden die 
zusaetzlichen Reste von Samba nicht gewaehrt.


> Ein 0777 als zugriffsrechte gäbe alles für alle zum lesen, schreiben,
> Ausführen/durchsuchen frei. Ein 0700 nur für dich als owner, 0770 dann
> für dich und die Familie und die weiteren Abstufungen für RWX darfst du
> gern selbst in den man pages nach schlagen.
>

Inzwischen weiss ich, wie chmod geht :-)


>> Die Berechtigungen sind natuerlich auch nochmal in der smb.conf des NAS
>> festgelegt. Da dies bei Samba mit Unterverzeichnissen unhandlich wird,
>> muesste ich den Datensatz in drei Teile zerlegen (nur ich, Familie,
>> alle) und jeden Teil einzeln als Samba Share rausgeben. Ist machbar.
>> Reicht das prinzipiell?
>
> Schon richtig. Für jede Gruppe ein Share ein zu richten ist dann
> einfacher. Dann kann man dem Samba z.b. auch sagen welcher user lese und
> schreib zugriff haben darf. FYI hier:
>
> https://www.samba.org/samba/docs/using_samba/ch08.html
>
> Wenn du also die benutzer joerg, frau, kind (o.ä.) im Linux und in Samba
> als Benutzer hättest und dazu eine benutzergruppe Family der all diese
> Benutzer zugeordnet sind dann kannst du z.b. dein Homedir oder ein
> weiteres share für deine eigenen Dateien nehmen. Dann ein [family] share
> das der gruppe family zugeordnet ist und ein [public] share das alle
> ohne schutz benutzen dürften.
>
> Beim Family Share muß das verzeichnis hinter dem share auf dem NAS aber
> auch für diese gruppe schreibrechte haben.
>

Ja, das ist es, was ich anfangs nicht wusste. Rechtevergabe in smb.conf 
nutzen nichts, wenn nicht mindestens die gleichen Rechte in den Files 
liegen.


>> Auf den Rechnern selbst ist es weniger wichtig, da die betreffenden
>> Rechner nur von mir benutzt werden und Password-Schutz haben. Aber nach
>> Sync von der FAT32 Partition aus gaebe es dann, so wie ich es verstehe,
>> fuer die betreffenden Files wegen Ueberschreibens keine
>> Zugriffsbeschraenkungen mehr auf der ext3 Partition des NAS.
>
> Wenn du ein Share hast das nur du beschreiben darfst und von der FAT
> Datenpartition dort *nur* Dateien rein schiebst die du lesen/schreiben
> darfst dann werden die dort auch so gespeichert werden. Wenn das share
> so eingerichtet ist. Denn samba setzt für neue Files und Directorys die
> Berechtigungen auf dem Zieldateisystem (bei dir ext3) so wie du es ihm
> vorgibst. Ebenso kannst du dann mit einem Familien-share verfahren und
> mit dem das alle anderen nutzen dürfen. Public=yes kannst du bei
> letzterem z.b. setzen damit alle ohne schutz drauf zugreifen dürften.
>
> Du mußt evtl. noch die Umsetzung der DOS Attribute auf die
> linux-dateirechte beachten oder umkonfigurieren. Aber wenn es nur
> datendateien sind die kein hidden oder system attribut brauchen, dürfte
> das keine Probleme machen.
>

Ich habe ein wenig hin und her geschoben, geschrieben, mit Windows und 
Linux. Textbearbeitung mache ich jetzt immer in Linux, aber 
erstaunlicherweise haben sich die Rechte nicht geaendert, als ich einen 
File auf OpenOffice im Windows Boot erstellte und aufs NAS schrieb.


> Wenn auf die freigabe [joerg] nur der samba- und system-user joerg
> zugreifen darf, auf die freigabe [family] nur die Mitglieder der Gruppe
> family (inkl. dir selbst) und auf die Freigabe [public] alle dann sollte
> das schon so reichen. Meine ich, der ich dabei nun auch kein Echter
> Experte bin.
>
> Uff. Eigentlich wollte ich nicht so viel schreiben. Hoffe es hilft.
>

Danke, das tut es. Es sieht so aus, als ob NTFS als Partition auf dem 
Rechner und ext3 auf dem NAS zusammen funktionieren. Aendern kann ich 
das ja spaeter immer noch, durch Neuformatieren.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#110992

Am 12.06.20 um 23:40 schrieb Joerg:
>>> On 2020-06-09 13:39, Kay Martinen wrote:
>>>> Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows
>>>> festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem
>>>> weil das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen
> 
> Danke, das tut es. Es sieht so aus, als ob NTFS als Partition auf dem
> Rechner und ext3 auf dem NAS zusammen funktionieren. Aendern kann ich
> das ja spaeter immer noch, durch Neuformatieren.

Hörst du wieder nicht zu? Du willst Dateirechte auf dem NAS aber nicht
auf den Clients. Ich sag dir nimm fat das kennt keine und erkläre dir
wie's damit auf dem NAS liefe via smb auf ext3. Und du, nimmst NTFS
statt FAT.

NTFS KENNT Dateirechte und unter Windows werden die auch benutzt. Wenn
du dann probleme beim Kopieren von Windows aufs NAS bekommst brauchst du
mich nicht zu fragen. Ich bin hier erst mal wieder raus.

Kay

-- 
Posted via SN

[toc] | [prev] | [next] | [standalone]

#111013

On 2020-06-12 15:29, Kay Martinen wrote:
> Am 12.06.20 um 23:40 schrieb Joerg:
>>>> On 2020-06-09 13:39, Kay Martinen wrote:
>>>>> Dann würde ich eine FAT32 Partition im Freien Bereich hinter Windows
>>>>> festlegen kannst. Damit hast du dann auch kein Berechtigungsproblem
>>>>> weil das Dateisyetem das eh nicht kennt. Also auch kein Streß beim Syncen
>>
>> Danke, das tut es. Es sieht so aus, als ob NTFS als Partition auf dem
>> Rechner und ext3 auf dem NAS zusammen funktionieren. Aendern kann ich
>> das ja spaeter immer noch, durch Neuformatieren.
>
> Hörst du wieder nicht zu? ...


Hey, das war erstmal nur ein Test :-)


>                 ... Du willst Dateirechte auf dem NAS aber nicht
> auf den Clients. Ich sag dir nimm fat das kennt keine und erkläre dir
> wie's damit auf dem NAS liefe via smb auf ext3. Und du, nimmst NTFS
> statt FAT.
>

Da muesste ich wohl exFAT nehmen, weil z.B. Thunderbirs alles in einen 
fetten File packt, der ueber 4GB gross ist.


> NTFS KENNT Dateirechte und unter Windows werden die auch benutzt. Wenn
> du dann probleme beim Kopieren von Windows aufs NAS bekommst brauchst du
> mich nicht zu fragen. Ich bin hier erst mal wieder raus.
>

Ich war allerdings erstaunt, dass die Rechte der urspruenglichen ext3 
Files auch nach mehrmaligem Schreiben und hin und her Kopieren immer 
noch die gleichen waren wie vorher. Windows hat die nicht angetatzt. 
Aber stimmt schon, passieren koennte das eines Tages.

Waere FAT oder exFAT denn sicher, wenn der Computer mit dieser 
Daten-Partition (in Linux) per Web Browser und so weiter ans Internet 
geht? Einschraenkungen in den Rechten gaebe es dann ja nicht mehr.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#111033

Joerg <news@analogconsultants.com>:

>Waere FAT oder exFAT denn sicher, wenn der Computer mit dieser
>Daten-Partition (in Linux) per Web Browser und so weiter ans
>Internet geht? Einschraenkungen in den Rechten gaebe es dann ja
>nicht mehr.

Das kommt darauf an, wer das FAT‐Dateisystem einhängt. 

In dem FAT‐Dateisystem wird bei den darin enthaltenen Dateien
weder eine Eigentümerschaft und Gruppenzugehörigkeit noch
Informationen über Zugriffserlaubnisse für den Eigentümer, die
Gruppe und alle anderen (abgesehen vielleicht vom Schreibzugriff)
vermerkt. 

Da unter Linux aber jede Datei eine Eigentümerschaft, eine
Gruppenzugehörigkeit und Informationen über Zugriffserlaubnisse
zumindest für den Eigentümer, die Gruppe und alle anderen haben
muss, müssen die Informationen woanders her kommen.  Dazu
übernimmt der Linuxkern entweder die Benutzerkennung und die
Hauptgruppenkennung des Prozesses, der das Dateisystem einhängt,
oder die Benutzer‐ und Gruppenkennungen können beim Einhängen als
Parameter angegeben werden.  Näheres dazu müsste im Handbuch
«mount(8)» stehen. 

Bei Wechselmedien ist so etwas genau richtig:  Wenn ich etwa einen
Ansteckspeicher, eine Diskette oder eine CD an einem Rechner
anschließe, ist davon auszugehen, dass der Inhalt des Dateisystems
sowieso unter meiner Kontrolle ist – schließlich habe ich das
Dateisystem mitgebracht.  Da ist es konsequent, wenn Linux beim
Einhängen des Dateisystems allen Dateien darin mich als Eigentümer
und meine Hauptgruppe als Gruppe zuordnet.  Wenn ich dann noch
beim Einhängen die Zugriffserlaubnisse für den Eigentümer, die
Gruppe und alle anderen wählen kann, bleibt die Sicherheit
genau so gewahrt, wie es bei den Dateien, die in meinem
HOME‐Verzeichnis sind, ist. 

Etwas anders liegt der Fall bei im Rechner eingebauten
Massenspeichern.  Da hätte die Regel «Wer das FAT‐Dateisystem
einhängt, dem gehört alles, was darin enthalten ist», zur Folge,
dass dieselben Dateien, die gestern dem, der es eingehängt hatte,
zugeschrieben wurden, heute mir gehören, wenn ich das Dateisystem
einhänge.  Sie werden also durch das Einhängen an den Einhängenden
«übergeben».  Das kann je nach Anwendungsfall sinnvoll sein oder
nicht. 

Wenn so ein Dateisystem also immer im Rechner verbleibt, ist es
meistens eher sinnvoll, wenn der Administrator das Dateisystem
gleich beim Hochfahren des Rechners einhängen lässt und zwar so,
dass alle Dateien darin die Eigentümerschaft «root» und die
Gruppenzugehörigkeit zu einer Gruppe, der alle diejenigen
angehören, die auf das Dateisystem zugreifen dürfen, haben.  Wenn
man dann die Zugriffsrechte auf den Eigentümer («root») und die
Gruppe (der alle vertrauenswürdigen Leute angehören) einschränkt,
also für alle übrigen verbietet, kann auch da keine
Privilegien‐Eskalation stattfinden. 

Wenn du der einzige bist, der Zugriff darauf haben soll, kannst du
das Einhängen auch so konfigurieren, dass du Eigentümer aller
Dateien bist, egal, ob es nun ein Wechselmedium oder ein fest
installiertes ist. 

Nochmals zitiert:

>Waere FAT oder exFAT denn sicher, wenn der Computer mit dieser
>Daten-Partition (in Linux) per Web Browser und so weiter ans
>Internet geht?

Das hängt davon ab, ob alle, die auf das Dateisystem zugreifen
dürfen, nicht nur vertrauenswürdig sondern auch kundig sind. 

Beispielsweise ist es keine gute Idee, ein Programm, was ich oder
jemand anderes aus dem Internet heruntergeladen hat, einfach
auszuführen, ohne sich vorher vergewissert zu haben, was es tut. 
Das erfordert einerseits Wissen um die Gefahr und andererseits
angemessene Sorgfalt. 

Unter Windows kann dabei SRP helfen, unter Linux, im PATH nur
absolute Pfade stehen zu haben (sonst gibt es «Nudelsuppe»), und
eventuell auch für das FAT‐Dateisystem die «noexec»‐Mount‐Option
(siehe das Handbuch «mount(8)»). 

[toc] | [prev] | [next] | [standalone]

#111059

Am 14.06.20 um 15:03 schrieb Helmut Waitzmann:

> Bei Wechselmedien ist so etwas genau richtig:  Wenn ich etwa einen
> Ansteckspeicher, eine Diskette oder eine CD an einem Rechner
> anschließe, ist davon auszugehen, dass der Inhalt des Dateisystems
> sowieso unter meiner Kontrolle ist – schließlich habe ich das
> Dateisystem mitgebracht.

Wenn ich ein USB-stick mit ext4 formatiere,
dürfte das nicht mehr zutreffen.

Hermann
    der sich da dann auch ein Unterordner mit users und $HOSTNAME
    angelegt hat.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#111070

Hermann Riemann <nospam.ng@hermann-riemann.de>:
>Am 14.06.20 um 15:03 schrieb Helmut Waitzmann:
>
>> Bei Wechselmedien ist so etwas genau richtig:  Wenn ich etwa 
>> einen Ansteckspeicher, eine Diskette oder eine CD an einem 
>> Rechner anschließe, ist davon auszugehen, dass der Inhalt des 
>> Dateisystems sowieso unter meiner Kontrolle ist – schließlich 
>> habe ich das Dateisystem mitgebracht.
>
>Wenn ich ein USB-stick mit ext4 formatiere, dürfte das nicht mehr 
>zutreffen.

Vielleicht wurde nicht klar, was ich meine:  


Wenn ich einen Ansteckspeicher mit Ext4‐Dateisystem an meinen 
Rechner anstecke, kann ich Dateien und Verzeichnisse drauf tun, 
wie ich will, weil ich bei mir zuhause auch Administrator bin. 

=> Der Inhalt des Ansteckspeichers ist unter meiner Kontrolle.  


Wenn ich den Ansteckspeicher dann an Deinen Rechner anstecke, ist 
es nicht sinnvoll, wenn Dein Rechner die Benutzer‐ und 
Gruppenkennungen der Dateien in dem angesteckten Dateisystem ernst 
nimmt:  Schließlich könnte ich ohne weiteres zuhause auf den 
Ansteckspeicher beispielsweise das Programm «/bin/nice» drauf 
getan und es zum Set‐User‐Id‐Root‐Programm gemacht haben, denn ich 
bin auf meiner Maschine auch Administrator. 

Dann stecke ich den Ansteckspeicher an Deinen Rechner an, hänge 
ihn als Ext4‐Dateisystem mit vollen Rechten beispielsweise in 
«/media/helmut/» ein und habe sofort das Set‐User‐Id‐Root‐Programm 
«/media/helmut/bin/nice» zur Verfügung.  Mit dem Shell‐Kommando

   /media/helmut/bin/nice -n 0 -- vi -- /etc/passwd

kann ich mir dann in Deiner Benutzerdatenbank einen Account mit 
der numerischen Kennung 0 verschaffen und bin damit auf Deiner 
Maschine «root». 

Um solche Katastrophen zu vermeiden, dürfen von Benutzern 
ansteckbare Dateisysteme (effektiv) keine Dateien mit anderen 
Benutzerkennungen als der Kennung dessen, der das Dateisystem 
angesteckt hat, enthalten. 

Die Methode der Wahl dafür ist, dass der Administrator des 
Rechners, an den fremde Ansteckspeicher angesteckt werden dürfen 
sollen, seinen Rechner so konfiguriert, dass die Benutzerkennungen 
auf dem angesteckten Dateisystem ignoriert werden und an deren 
Stelle die Benutzerkennung desjenigen, der es angesteckt hat, 
tritt. 

Ob es für Ext4‐Dateisysteme eine entsprechende Option zum 
«mount»‐Programm gibt, weiß ich jetzt nicht.  Falls es sie nicht 
gibt, würde ich meinen Rechner so konfigurieren, dass man keine 
Ext4‐Dateisysteme anstecken kann. 

[toc] | [prev] | [next] | [standalone]

#111083

Am 16.06.20 um 00:09 schrieb Helmut Waitzmann:
> Hermann Riemann <nospam.ng@hermann-riemann.de>:
>> Am 14.06.20 um 15:03 schrieb Helmut Waitzmann:
>>
>>> Bei Wechselmedien ist so etwas genau richtig:  Wenn ich etwa einen 
>>> Ansteckspeicher, eine Diskette oder eine CD an einem Rechner 
>>> anschließe, ist davon auszugehen, dass der Inhalt des Dateisystems 
>>> sowieso unter meiner Kontrolle ist – schließlich habe ich das 
>>> Dateisystem mitgebracht.
>>
>> Wenn ich ein USB-stick mit ext4 formatiere, dürfte das nicht mehr 
>> zutreffen.
> 
> Vielleicht wurde nicht klar, was ich meine:
> 
> Wenn ich einen Ansteckspeicher mit Ext4‐Dateisystem an meinen Rechner 
> anstecke, kann ich Dateien und Verzeichnisse drauf tun, wie ich will, 
> weil ich bei mir zuhause auch Administrator bin.
> 
> => Der Inhalt des Ansteckspeichers ist unter meiner Kontrolle.
> 
> Wenn ich den Ansteckspeicher dann an Deinen Rechner anstecke, ist es 
> nicht sinnvoll, wenn Dein Rechner die Benutzer‐ und Gruppenkennungen der 
> Dateien in dem angesteckten Dateisystem ernst nimmt:

SuSE PC_stick mit yast auf ext4 formatiert
# cd /run/media/stickname
# mkdir x
# chgrp users x
# chown my_hostame x
# exit
 > cd /run/media/stickname/x
 > echo bla > y
PC_stick abmelden
PC_stick rausrupfen und in raspberry pi stecken
PC_stick anmelden # userid is pi und nicht my_hostname
ls -l /*/y zeigt als users und pi an
und nicht users und my_hostname

Es wird nach meiner Einschätzung
nicht der username sondern die userid ( 500 ) übertragen.


>  Schließlich könnte 
> ich ohne weiteres zuhause auf den Ansteckspeicher beispielsweise das 
> Programm «/bin/nice» drauf getan und es zum Set‐User‐Id‐Root‐Programm 
> gemacht haben, denn ich bin auf meiner Maschine auch Administrator.

Was passiert,
wenn $HOME/bin ein *.sh datei sudo su enthält
habe ich noch nicht getestet

>    /media/helmut/bin/nice -n 0 -- vi -- /etc/passwd

Ich dachte als su in /etc/passwd bzw /etc/shadow Passwörter löschen
dann ein neue Passwörter vergeben ..

Hermann
    der den username in pi nicht ändern konnte,
    was die Dateiübertragung per USB-Geräte nicht gestört hat.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#111091

Hermann Riemann <nospam.ng@hermann-riemann.de>:
>Am 16.06.20 um 00:09 schrieb Helmut Waitzmann:

>> Wenn ich den Ansteckspeicher dann an Deinen Rechner anstecke, 
>> ist es nicht sinnvoll, wenn Dein Rechner die Benutzer‐ und 
>> Gruppenkennungen der Dateien in dem angesteckten Dateisystem 
>> ernst nimmt:
>
>SuSE PC_stick mit yast auf ext4 formatiert
># cd /run/media/stickname
># mkdir x
># chgrp users x
># chown my_hostame x
># exit
>> cd /run/media/stickname/x
>> echo bla > y
>PC_stick abmelden
>PC_stick rausrupfen und in raspberry pi stecken
>PC_stick anmelden # userid is pi und nicht my_hostname
>ls -l /*/y zeigt als users und pi an
>und nicht users und my_hostname
>
>Es wird nach meiner Einschätzung nicht der username sondern die 
>userid ( 500 ) übertragen.
>

Genau.  Im Ext4‐Dateisystem stehen keine Benutzer‐ und 
Gruppen‐Namen sondern nur die numerischen Benutzer‐ und 
Gruppen‐Kennungen.  Für die Zugriffskontrolle im 
Betriebssystemkern kommt es ja auch nur auf die numerischen 
Kennungen an.  Das bedeutet dann aber gerade, dass ein 
Set‐User‐Id‐Programm mit Benutzerkennung 0 auf dem 
Ext4‐Ansteckspeicher ein Root‐Set‐User‐Id‐Programm, also 
allmächtig ist: 

>>   Schließlich könnte ich ohne weiteres zuhause auf den 
>> Ansteckspeicher beispielsweise das Programm «/bin/nice» drauf 
>> getan und es zum Set‐User‐Id‐Root‐Programm gemacht haben, denn 
>> ich bin auf meiner Maschine auch Administrator.

>>    /media/helmut/bin/nice -n 0 -- vi -- /etc/passwd
>
>Ich dachte als su in /etc/passwd bzw /etc/shadow Passwörter 
>löschen dann ein neue Passwörter vergeben ..

Das fällt zu sehr auf, weil sich dann der rechtmäßige Eigentümer 
des Benutzernamens infolge des geänderten Passworts nicht mehr 
einloggen kann.  Besser ist es, heimlich einen neuen Benutzernamen 
hinzuzufügen und dem die numerische Kennung 0 zu verpassen. 

[toc] | [prev] | [next] | [standalone]

#111094

Am 16.06.20 um 10:22 schrieb Helmut Waitzmann:

 > Das bedeutet dann aber gerade, dass ein
> Set‐User‐Id‐Programm mit Benutzerkennung 0 auf dem 
> Ext4‐Ansteckspeicher ein Root‐Set‐User‐Id‐Programm, also allmächtig
> ist:

Weshalb alle mir bekannten Distributionen USB-Speicher mit der Option 
"nosuid" mounten.


-- 
Grüße
Gert

[toc] | [prev] | [next] | [standalone]

#111096

Am 16.06.20 um 10:22 schrieb Helmut Waitzmann:
> Hermann Riemann <nospam.ng@hermann-riemann.de>:
>> Am 16.06.20 um 00:09 schrieb Helmut Waitzmann:

>>> Wenn ich den Ansteckspeicher dann an Deinen Rechner anstecke, ist es 
>>> nicht sinnvoll, wenn Dein Rechner die Benutzer‐ und Gruppenkennungen 
>>> der Dateien in dem angesteckten Dateisystem ernst nimmt:

>> SuSE PC_stick mit yast auf ext4 formatiert
>> # cd /run/media/stickname
>> # mkdir x
>> # chgrp users x
>> # chown my_hostname x
>> # exit
>>> cd /run/media/stickname/x
>>> echo bla > y
>> PC_stick abmelden
>> PC_stick rausrupfen und in raspberry pi stecken
>> PC_stick anmelden # userid is pi und nicht my_hostname
>> ls -l /*/y zeigt als users und pi an
>> und nicht users und my_hostname

>> Es wird nach meiner Einschätzung nicht der username sondern die userid 
>> ( 500 ) übertragen.

> Genau.  Im Ext4‐Dateisystem stehen keine Benutzer‐ und Gruppen‐Namen 
> sondern nur die numerischen Benutzer‐ und Gruppen‐Kennungen.  Für die 
> Zugriffskontrolle im Betriebssystemkern kommt es ja auch nur auf die 
> numerischen Kennungen an.

Ich vermute, es hat noch einen anderen Effekt:

In einem Haushalt leben Adam und Eva.
Jede Person hat ein PC mit Linux
Person Adam mit $HOSTNAME adam
Person Eva  mit $HOSTNAME eva.

Um bei PCs ausweichen können richtet
Adam später einen user mit $HOSTNAME eva ein und
Eva  später einen user mit $HOSTNAME adam.

Jetzt machen beide zwecks Datenaustausch
obiges Verfahren

Ergebnis,
Wenn dann das USB-Gerät gewechselt wird,
kann ohne su Adam nur auf USB-Daten von eva zugreifen
nicht aber auf die von Adam.
Und umgekehrt.

( Kann bei Datensicherung mit rsync auf falschem Gerät
   unerwünschte Wirkung haben. )

Hermann
    der hofft nach Änderung von userid Zuordnungen
    durch neue Linux Versionen
    wenigstens noch als root auf seine Sicherungen
    zugreifen zu können

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#111416

Hallo!

* Hermann Riemann <nospam.ng@hermann-riemann.de>:

> der den username in pi nicht ändern konnte,

  Bei mir hat "usermod --login newname pi" prima funktioniert.
Eventuell willst du das mit "--move-home" kombinieren.

Christoph

-- 
Nachdem heute abend unser Geschirrschrank ein Problem mit seiner
strukturellen Integritaet hatte, sind wir nun glueckliche Besitzer
einer groesseren Menge Porzellan- und Glasscherben.
(Nikki Britz)

[toc] | [prev] | [next] | [standalone]

#111085

Mahlzeit!

Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> Am 14.06.20 um 15:03 schrieb Helmut Waitzmann:
 
>> Bei Wechselmedien ist so etwas genau richtig:  Wenn ich etwa einen
>> Ansteckspeicher, eine Diskette oder eine CD an einem Rechner
>> anschließe, ist davon auszugehen, dass der Inhalt des Dateisystems
>> sowieso unter meiner Kontrolle ist – schließlich habe ich das
>> Dateisystem mitgebracht.
> 
> Wenn ich ein USB-stick mit ext4 formatiere,
> dürfte das nicht mehr zutreffen.
> 
> Hermann
>    der sich da dann auch ein Unterordner mit users und $HOSTNAME
>    angelegt hat.

Wenn ich Deinen Stick an meinen Rechner stecke, setze ich als root ein
chmod oder chown ab und dann sind Deine User-Berechtigungen wieder weg.

Das taugt nur dann als Schutz, wenn der Stick ausschließlich an die
von Dir administrierten Rechner gesteckt werden kann.  (Heißkleber?)

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de

[toc] | [prev] | [next] | [standalone]

#111087

Am 16.06.20 um 09:10 schrieb Christian Garbs:

>> Wenn ich ein USB-stick mit ext4 formatiere,
>> dürfte das nicht mehr zutreffen.

>> Hermann
>>     der sich da dann auch ein Unterordner mit users und $HOSTNAME
>>     angelegt hat.

> Wenn ich Deinen Stick an meinen Rechner stecke, setze ich als root ein
> chmod oder chown ab und dann sind Deine User-Berechtigungen wieder weg.

Die ganze Order Hierachrie?
Die Dateien dann nur als root anlegen ändern löschen?

> Das taugt nur dann als Schutz, wenn der Stick ausschließlich an die
> von Dir administrierten Rechner gesteckt werden kann.  (Heißkleber?)

Ich habe diese Eigenschaft verwendet,
um für die Benutzung der sticks oder USB-Festplatten
nicht unter su arbeiten zu müssen.

Das gilt auch für USB-Platten,
die ich nur auf einem PC verwende.

Hermann
    der Arbeit vermutet, wenn Linux eines Tages
    unterschiedliche userids für unterschiedliche computer verwendet.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#111102

Hermann Riemann <nospam.ng@hermann-riemann.de>:
>Am 16.06.20 um 09:10 schrieb Christian Garbs:
>
>>> Wenn ich ein USB-stick mit ext4 formatiere, 
>>> dürfte das nicht mehr zutreffen.
>
>> Wenn ich Deinen Stick an meinen Rechner stecke, setze ich als 
>> root ein chmod oder chown ab und dann sind Deine 
>> User-Berechtigungen wieder weg.
>
>Die ganze Order Hierachrie? 
>

Warum denn nicht?  Nach Ausführung der Kommandos 


   sudo -u root -i \
      find /media/christian/Hermanns_USB-Speicher/ \
     ! -type l ! -exec chown -- christian '{}' +

oder

   su -- - root -c '"$@"' su-shell \
      find /media/christian/Hermanns_USB-Speicher/ \
     ! -type l ! -exec chown -- christian '{}' +

gehört alles Christian.  

[toc] | [prev] | [next] | [standalone]

#111105

Hallo Hermann,

Du schriebst am Tue, 16 Jun 2020 09:32:00 +0200:

>     der Arbeit vermutet, wenn Linux eines Tages
>     unterschiedliche userids für unterschiedliche computer verwendet.

Hast Du da nicht was mißverstanden? Linux benutzt auch heute
"unterschiedliche userids für unterschiedliche computer", wenn das so
eingestellt wird.
Es gibt keine Vorschrift, wie die "userids" lauten müssen und welchen
Benutzers sie zuzuordnen sind, außer der einzig fest vorgegebenen Id "0".

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#111108

Hermann Riemann meinte:

>> Wenn ich Deinen Stick an meinen Rechner stecke, setze ich als root ein
>> chmod oder chown ab und dann sind Deine User-Berechtigungen wieder weg.
> 
> Die ganze Order Hierachrie?

man chown, option -R
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web