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

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

Rekursives Recht auch fuer neu erstellte Directories moeglich?

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

Contents

  Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-02 13:22 -0700
    Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-03 06:43 +0000
      Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-03 13:04 -0700
        Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Jens Schüßler <jgs@trash.net> - 2020-08-03 22:33 +0200
          Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-03 13:52 -0700
        Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-08-04 13:06 +0200
          Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-04 12:49 -0700
    Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-08-03 21:18 +0200
      Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-03 13:35 -0700
        Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-08-04 20:12 +0200
          Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-04 12:47 -0700
            Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-08-05 21:07 +0200
              Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-05 14:35 -0700
                Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-06 06:07 +0000
                  Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Thomas Noll <-_tn_-@web.de> - 2020-08-06 07:16 +0000
                    Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-06 12:28 +0000
                      Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-07 14:20 -0700
                        Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-08 07:09 +0000
                          Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-08 10:01 -0700
                            Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-09 19:10 +0000
                              Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Joerg <news@analogconsultants.com> - 2020-08-09 12:28 -0700
                Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-08-07 00:37 +0200
                  Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2020-08-07 06:40 +0000
                    Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-08-08 21:45 +0200
    Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? [geloest] Joerg <news@analogconsultants.com> - 2020-08-09 12:05 -0700
      Re: Rekursives Recht auch fuer neu erstellte Directories moeglich? [geloest] Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-08-12 09:17 +0200
        Re: Rekursives Recht auch fuer neu erstellte Directories moeglich?   [geloest] Joerg <news@analogconsultants.com> - 2020-08-15 12:22 -0700

Page 1 of 2  [1] 2  Next page →

#111494 — Rekursives Recht auch fuer neu erstellte Directories moeglich?

Nicht hauen, bin immer noch Anfaenger.

Mein NAS laeuft mit ArchLinux und hat im Wesentlichen zwei Bereiche. 
/Data ist fuer Daten, die nur mir und der Group zur Verfuegung stehen, 
manche nur mir. /Public hingegen ist fuer jeden, jeder darf schreiben. 
Die Rechte sind in smb.conf sowie in /mnt entsprechend gesetzt, ist 
alles paletti.

Wenn nun aber jemand in /Public eine neue Directory setzt, wird das 
erlaubt, er kann jedoch keine Files in diese neue Directory 
hineinkopieren. In alle anderen schon. Soweit ich das anhand der Man Page

https://linux.die.net/man/1/chmod

verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf bereits 
bestehende Directories, aber nicht auf neue unterhalb der 
Haupt-Directory. Nun kann man wohl noch irgendwo umask setzen, aber das 
erscheint mir suboptimal, weil das m.W. fuer alles gilt und ich moechte 
die Rechte zwischen diesen beiden Haupt-Directories unterschiedlich 
halten. Innerhalb /Public aber einheitlich und das moeglichst auch fuer 
neu erstellte Sub-Directories.

Ich koennte natuerlich fuer jede in /Public neu erzeugte Directory von 
Hand "chmod -R 666" oder was immer setzen, aber Besucher kennen Linux 
i.d.R. ueberhaupt nicht und das wuerde unbequem.

Kann man hier was schrauben?

Dann waere da noch ein merkwuerdiger Nebeneffekt, dass der Versuch, von 
einem Rechner im Windows Boot in /Public eine Directory zu erstellen, 
mit einem Absturz dessen File Explorers endet. Doch das ist wohl eine 
andere Baustelle und auch nicht mehr so wichtig.

BTW, ich weiss, man soll in Linux alles klein schreiben. Aber es sieht 
irgendwie seltsam aus und ich hoffe, /Public und aehnliches ist ok. 
Falls nicht, bitte ich um einen Wink mit dem Zaunpfahl :-)

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [next] | [standalone]

#111497

On Sun, 02 Aug 2020 22:22:23 Joerg wrote:
> Wenn nun aber jemand in /Public eine neue Directory setzt, wird
> das erlaubt, er kann jedoch keine Files in diese neue Directory
> hineinkopieren. In alle anderen schon. Soweit ich das anhand der
> Man Page

> https://linux.die.net/man/1/chmod
 
> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf
> bereits bestehende Directories, aber nicht auf neue unterhalb der
> Haupt-Directory.

Permissions für nicht vorhandene Verzeichnisse setzen ist auch eher
schwierig.

> Nun kann man wohl noch irgendwo umask setzen, aber das erscheint
> mir suboptimal, weil das m.W. fuer alles gilt und ich moechte die
> Rechte zwischen diesen beiden Haupt-Directories unterschiedlich 
> halten. [...]

In chmod(1) findet sich darauf leider kein Hinweis, aber wenn Du in
umask(2) nachliest, wird Dir als Alternative vorgeschlagen, bei
acl(5) weiterzulesen. Dort findest Du das, was Du suchst.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Plumpsen im Dröhnen der Motoren - Stefan!
(Sloganizer)

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

#111512

On 2020-08-02 23:43, Stefan Froehlich wrote:
> On Sun, 02 Aug 2020 22:22:23 Joerg wrote:
>> Wenn nun aber jemand in /Public eine neue Directory setzt, wird
>> das erlaubt, er kann jedoch keine Files in diese neue Directory
>> hineinkopieren. In alle anderen schon. Soweit ich das anhand der
>> Man Page
>
>> https://linux.die.net/man/1/chmod
>
>> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf
>> bereits bestehende Directories, aber nicht auf neue unterhalb der
>> Haupt-Directory.
>
> Permissions für nicht vorhandene Verzeichnisse setzen ist auch eher
> schwierig.
>

Technisch an sich nicht, aber das wurde vermutlich nicht so gemacht: Man 
koennte etwa per Default festlegen, dass saemtliche neu erstellten 
Unterverzeichnisse, Unter-Unterverzeichnisse und so weiter erstmal 
dieselben Permissions bekommen wie das Hauptverzeichnis. Es sei denn, 
der Ersteller waehlt andere Permissions und in dem Fall sollten die 
weiteren Verzeichnisse _unter_ diesem Unterverzeichnis ebenfalls dessen 
Wunsch-Permissions bekommen. So wuerde das Sinn machen.


>> Nun kann man wohl noch irgendwo umask setzen, aber das erscheint
>> mir suboptimal, weil das m.W. fuer alles gilt und ich moechte die
>> Rechte zwischen diesen beiden Haupt-Directories unterschiedlich
>> halten. [...]
>
> In chmod(1) findet sich darauf leider kein Hinweis, aber wenn Du in
> umask(2) nachliest, wird Dir als Alternative vorgeschlagen, bei
> acl(5) weiterzulesen. Dort findest Du das, was Du suchst.
>

Irgendwie erschliesst sich mir nicht, wie man das damit machen koennte.

https://www.man7.org/linux/man-pages/man5/acl.5.html

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111514

* Joerg <news@analogconsultants.com> [03-08-20 20:04]:
> On 2020-08-02 23:43, Stefan Froehlich wrote:
>> On Sun, 02 Aug 2020 22:22:23 Joerg wrote:
>>> Wenn nun aber jemand in /Public eine neue Directory setzt, wird
>>> das erlaubt, er kann jedoch keine Files in diese neue Directory
>>> hineinkopieren. In alle anderen schon. Soweit ich das anhand der
>>> Man Page
>>
>>> https://linux.die.net/man/1/chmod
>>
>>> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf
>>> bereits bestehende Directories, aber nicht auf neue unterhalb der
>>> Haupt-Directory.
>>
>> Permissions für nicht vorhandene Verzeichnisse setzen ist auch eher
>> schwierig.
>>
>
> Technisch an sich nicht, aber das wurde vermutlich nicht so gemacht: Man 
> koennte etwa per Default festlegen, dass saemtliche neu erstellten 
> Unterverzeichnisse, Unter-Unterverzeichnisse und so weiter erstmal 
> dieselben Permissions bekommen wie das Hauptverzeichnis. Es sei denn, 
> der Ersteller waehlt andere Permissions und in dem Fall sollten die 
> weiteren Verzeichnisse _unter_ diesem Unterverzeichnis ebenfalls dessen 

Glückwunsch, du hast gerade die sei Ewigkeiten existierenden Einstellungen 
zu "directory mask" und "create mask" in der smb.conf neu erfunden.
Aber kannst du ja nicht wissen, da du dich weigerst Dokumentation zu
lesen. Hättest du das getan, wüßtest du du auch, daß man die für jedes
Share differenziert setzen kann.

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

#111516

On 2020-08-03 13:33, Jens Schüßler wrote:
> * Joerg <news@analogconsultants.com> [03-08-20 20:04]:
>> On 2020-08-02 23:43, Stefan Froehlich wrote:
>>> On Sun, 02 Aug 2020 22:22:23 Joerg wrote:
>>>> Wenn nun aber jemand in /Public eine neue Directory setzt, wird
>>>> das erlaubt, er kann jedoch keine Files in diese neue Directory
>>>> hineinkopieren. In alle anderen schon. Soweit ich das anhand der
>>>> Man Page
>>>
>>>> https://linux.die.net/man/1/chmod
>>>
>>>> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf
>>>> bereits bestehende Directories, aber nicht auf neue unterhalb der
>>>> Haupt-Directory.
>>>
>>> Permissions für nicht vorhandene Verzeichnisse setzen ist auch eher
>>> schwierig.
>>>
>>
>> Technisch an sich nicht, aber das wurde vermutlich nicht so gemacht: Man
>> koennte etwa per Default festlegen, dass saemtliche neu erstellten
>> Unterverzeichnisse, Unter-Unterverzeichnisse und so weiter erstmal
>> dieselben Permissions bekommen wie das Hauptverzeichnis. Es sei denn,
>> der Ersteller waehlt andere Permissions und in dem Fall sollten die
>> weiteren Verzeichnisse _unter_ diesem Unterverzeichnis ebenfalls dessen
>
> Glückwunsch, du hast gerade die sei Ewigkeiten existierenden Einstellungen
> zu "directory mask" und "create mask" in der smb.conf neu erfunden.
> Aber kannst du ja nicht wissen, da du dich weigerst Dokumentation zu
> lesen. Hättest du das getan, wüßtest du du auch, daß man die für jedes
> Share differenziert setzen kann.
>

Die waren (sind) entsprechend eingestellt, hat aber nichts geholfen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111528

Joerg <news@analogconsultants.com> wrote:
>So wuerde das Sinn machen

Unix ist älter als Windows. Deswegen benimmt es sich anders als
Windows. Finde Dich damit ab. Es ist ein anderes Betriebssystem. Und
das wird man nach fünfzig Jahren auch nicht mehr ändern.

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

#111541

On 2020-08-04 04:06, Marc Haber wrote:
> Joerg <news@analogconsultants.com> wrote:
>> So wuerde das Sinn machen
>
> Unix ist älter als Windows. Deswegen benimmt es sich anders als
> Windows. Finde Dich damit ab. Es ist ein anderes Betriebssystem. Und
> das wird man nach fünfzig Jahren auch nicht mehr ändern.
>

Marcel hat die Loesung aufgezeigt. Ich muss sie jetzt nur noch ans 
Laufen bekommen. Das ist alles nicht "mission-critical", aber 
langfristig sollte das schon funktionieren, damit auch andere das NAS 
benutzen koennen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111508

Am 02.08.20 um 22:22 schrieb Joerg:
> Wenn nun aber jemand in /Public eine neue Directory setzt, wird das 
> erlaubt, er kann jedoch keine Files in diese neue Directory 
> hineinkopieren. In alle anderen schon. Soweit ich das anhand der Man Page
> 
> https://linux.die.net/man/1/chmod
> 
> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf bereits 
> bestehende Directories, aber nicht auf neue unterhalb der 
> Haupt-Directory.

Exakt. Die werden immer mit User und primärer Gruppe des Users erstellt.
Ausnahme: das s-Bit. Und das ist mutmaßlich auch schon die Lösung.

Setze in allen Verzeichnissen (und nur da!) das s-Bit. Dann erben alle 
/neu erstellten/ Dateien und Verzeichnisse in diesen Ordnern dessen 
Gruppe, unabhängig von der Gruppe des Users.

   find Public -type d -exec chmod g+s {}\;

> Nun kann man wohl noch irgendwo umask setzen, aber das 
> erscheint mir suboptimal, weil das m.W. fuer alles gilt und ich moechte 
> die Rechte zwischen diesen beiden Haupt-Directories unterschiedlich 
> halten.

umask ist was anderes. Für samba public shares empfehle ich 002. Dann 
kann man mit den Gruppen die Schreibrechte beeinflussen und mit den 
x-Bits der übergeordneten Verzeichnisse die Leserechte. Das reicht 
normalerweise für den Hausgebrauch.

Für das HOME-Share kann man auch 022 nehmen. Ich bevorzuge allerdings 
auch da die Sache mit den x-Bits auf den Verzeichnissen.

> Innerhalb /Public aber einheitlich und das moeglichst auch fuer 
> neu erstellte Sub-Directories.

Ja, eindeutig eine Sache für's s-Bit.


> BTW, ich weiss, man soll in Linux alles klein schreiben. Aber es sieht 
> irgendwie seltsam aus und ich hoffe, /Public und aehnliches ist ok. 
> Falls nicht, bitte ich um einen Wink mit dem Zaunpfahl :-)

Das ist total egal. Du musst dir nur darüber im klaren sein, dass Du es 
dann immer gleich schreiben musst, denn Linux ist case-sensitive. Das 
geht auch kaum anders, denn die Groß-Klein-Äquivalenz ist 
sprachspezifisch und Unix-Dateinamen sind technisch gesehen binär und 
nicht Unicode. Wie das benutzende Programm die binären Namen 
interpretiert, ist dem System egal.

Anders ist die Sache bei Samba. Der führt eine Konvertierung der 
SMB-Namen des Clients (üblicherweise UTF-16) in die Codepage des 
Samba-Servers (sinnvollerweise identisch mit der des Systems) durch. 
Üblicherweise ist das in unseren Breiten UTF-8.
Ferner matcht Samba bei Windows-Clients case-insenitiv. Das kann in 
Einzelfällen zu unerwarteten Verhalten führen, wenn es einen Namen in 
einem Verzeichnis doppelt, nur mit unterschiedlicher 
Groß-Kleinschreibung gibt. Über Samba könnte man das aber nicht anlegen.


Marcel

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

#111513

On 2020-08-03 12:18, Marcel Mueller wrote:
> Am 02.08.20 um 22:22 schrieb Joerg:
>> Wenn nun aber jemand in /Public eine neue Directory setzt, wird das
>> erlaubt, er kann jedoch keine Files in diese neue Directory
>> hineinkopieren. In alle anderen schon. Soweit ich das anhand der Man Page
>>
>> https://linux.die.net/man/1/chmod
>>
>> verstehe, wirkt das von mir benutzte "chmod -R" rekursiv nur auf
>> bereits bestehende Directories, aber nicht auf neue unterhalb der
>> Haupt-Directory.
>
> Exakt. Die werden immer mit User und primärer Gruppe des Users erstellt.
> Ausnahme: das s-Bit. Und das ist mutmaßlich auch schon die Lösung.
>

Aha, das kommt der Sache naeher. Ich kannte bisher nur das sticky Bit, 
aber das hat damit ja nichts zu tun.

https://unix.stackexchange.com/questions/182212/chmod-gs-command

Zitat "This means that all new files and subdirectories created within 
the current directory inherit the group ID of the directory, rather than 
the primary group ID of the user who created the file. This will also be 
passed on to new subdirectories created in the current directory.

Danke! Das ist wohl die Richtung, in die ich gehen muss.


> Setze in allen Verzeichnissen (und nur da!) das s-Bit. Dann erben alle
> /neu erstellten/ Dateien und Verzeichnisse in diesen Ordnern dessen
> Gruppe, unabhängig von der Gruppe des Users.
>
>    find Public -type d -exec chmod g+s {}\;
>

Das ergab:

[root@alarm joerg]# find Public -type d -exec chmod g+s {}\;
find: missing argument to `-exec'

Da muss ich mich wohl erst mal einlesen :-)

Vielleicht ginge

chmod g+s /mnt/SD/Public

aber das muss ich erst nachlesen, ehe ich mir das ganze OS des NAS 
zerschiesse.


>> Nun kann man wohl noch irgendwo umask setzen, aber das erscheint mir
>> suboptimal, weil das m.W. fuer alles gilt und ich moechte die Rechte
>> zwischen diesen beiden Haupt-Directories unterschiedlich halten.
>
> umask ist was anderes. Für samba public shares empfehle ich 002. Dann
> kann man mit den Gruppen die Schreibrechte beeinflussen und mit den
> x-Bits der übergeordneten Verzeichnisse die Leserechte. Das reicht
> normalerweise für den Hausgebrauch.
>
> Für das HOME-Share kann man auch 022 nehmen. Ich bevorzuge allerdings
> auch da die Sache mit den x-Bits auf den Verzeichnissen.
>

Ist wahrscheinlich besser, aber soweit bin ich noch nicht. Ich wollte 
die Sache erstmal verstehen und spaeter versuchen, daran zu schrauben.


>> Innerhalb /Public aber einheitlich und das moeglichst auch fuer neu
>> erstellte Sub-Directories.
>
> Ja, eindeutig eine Sache für's s-Bit.
>

Danke, sieht so aus. Das sollte das Problem loesen.

>
>> BTW, ich weiss, man soll in Linux alles klein schreiben. Aber es sieht
>> irgendwie seltsam aus und ich hoffe, /Public und aehnliches ist ok.
>> Falls nicht, bitte ich um einen Wink mit dem Zaunpfahl :-)
>
> Das ist total egal. Du musst dir nur darüber im klaren sein, dass Du es
> dann immer gleich schreiben musst, denn Linux ist case-sensitive. Das
> geht auch kaum anders, denn die Groß-Klein-Äquivalenz ist
> sprachspezifisch und Unix-Dateinamen sind technisch gesehen binär und
> nicht Unicode. Wie das benutzende Programm die binären Namen
> interpretiert, ist dem System egal.
>

Gut, dann kann ich das so lassen. Ich hatte nur gefragt, weil viele 
meinten, dass z.B. User Names in Linux kleingeschrieben sein sollen. 
Damit ist meiner nun anders als in Windows.


> Anders ist die Sache bei Samba. Der führt eine Konvertierung der
> SMB-Namen des Clients (üblicherweise UTF-16) in die Codepage des
> Samba-Servers (sinnvollerweise identisch mit der des Systems) durch.
> Üblicherweise ist das in unseren Breiten UTF-8.
> Ferner matcht Samba bei Windows-Clients case-insenitiv. Das kann in
> Einzelfällen zu unerwarteten Verhalten führen, wenn es einen Namen in
> einem Verzeichnis doppelt, nur mit unterschiedlicher
> Groß-Kleinschreibung gibt. Über Samba könnte man das aber nicht anlegen.
>

Ich hoffe, dass dann vor einem moeglichen Knall eine Warnung kommt :-)

Darauf habe ich auch nicht immer Einfluss, weil ich einige File Sets von 
woanders bekomme.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111538

Hallo Joerg,

Du schriebst am Mon, 03 Aug 2020 13:35:38 -0700:

> Aha, das kommt der Sache naeher. Ich kannte bisher nur das sticky Bit, 
> aber das hat damit ja nichts zu tun.

Sag'mal, liest Du eigentlich nur die Antworten auf Deine Fragen?
Genau zu dem Thema hat Helmut Waitzmann vor nicht langer Zeit eine längere
Abhandlung (so könnte man das nennen) geschrieben. Der Frager warst zwar
AFAIR nicht Du, aber das Thema war genau das Deiner Frage hier.
Mußt halt mal bisserl danach suchen, ich hab' mir das nicht alles
aufgehoben und gemerkt. Nur soviel: er hat da nicht nur das "sticky"-Bit
angesprochen, sondern auch die Wirkungen der andern Zusatz-Bits, z.B.
"suid user" und "suid group", bei Verzeichnissen. Es war ein sehr
ausführliches Posting, und wie praktisch alle seiner Postings sehr
informativ. (Du wirst Dich zwar bisserl schwertun mit seiner sehr stark
deutsch orientierten Ausdrucksweise und ein paar Eigenheiten, aber das
dürfte sich durchaus lohnen.)

...
> >    find Public -type d -exec chmod g+s {}\;
                                             ^ - da fehlt ein"space".
> [root@alarm joerg]# find Public -type d -exec chmod g+s {}\;
> find: missing argument to `-exec'

Und daher kommt die Fehlermeldung.

> Da muss ich mich wohl erst mal einlesen :-)

Aber "find" ist durchaus ein bisserl "einlesen" wert.

> Vielleicht ginge
> 
> chmod g+s /mnt/SD/Public

Sicher geht das, wenn Du das so haben willst.

> aber das muss ich erst nachlesen, ehe ich mir das ganze OS des NAS 
> zerschiesse.

Also noch kein "Wizard Of Oz^HS"...

...
> Ist wahrscheinlich besser, aber soweit bin ich noch nicht. Ich wollte 
> die Sache erstmal verstehen und spaeter versuchen, daran zu schrauben.

Du _könntest_ auch mal Empfehlungen (an unkritischen Beispielen)
ausprobieren und annehmen, wenn sie Dir taugen. Später verstehen wollen ist
ja in Ordnung, aber dann "erstmal" stattdessen selbergezimmerte Krücken
dafür zu benutzen ist halt durchaus "suboptimal". Man könnte aus Deiner
Reaktion fast schließen mögen, Du littest unter dem "NIH-Syndrom"...

-- 
-- 
(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]

#111540

On 2020-08-04 11:12, Sieghard Schicktanz wrote:
> Hallo Joerg,
>
> Du schriebst am Mon, 03 Aug 2020 13:35:38 -0700:
>
>> Aha, das kommt der Sache naeher. Ich kannte bisher nur das sticky Bit,
>> aber das hat damit ja nichts zu tun.
>
> Sag'mal, liest Du eigentlich nur die Antworten auf Deine Fragen?
> Genau zu dem Thema hat Helmut Waitzmann vor nicht langer Zeit eine längere
> Abhandlung (so könnte man das nennen) geschrieben. Der Frager warst zwar
> AFAIR nicht Du, aber das Thema war genau das Deiner Frage hier.
> Mußt halt mal bisserl danach suchen, ich hab' mir das nicht alles
> aufgehoben und gemerkt. Nur soviel: er hat da nicht nur das "sticky"-Bit
> angesprochen, sondern auch die Wirkungen der andern Zusatz-Bits, z.B.
> "suid user" und "suid group", bei Verzeichnissen. Es war ein sehr
> ausführliches Posting, und wie praktisch alle seiner Postings sehr
> informativ. (Du wirst Dich zwar bisserl schwertun mit seiner sehr stark
> deutsch orientierten Ausdrucksweise und ein paar Eigenheiten, aber das
> dürfte sich durchaus lohnen.)
>

Ich suche vor Postings hier schon intensiv, allerdings nicht in 
deutscher Sprache, weil die nicht mehr so gut sitzt bei mir und ich auch 
deutsche Computer-Ausdruecke nicht kenne (aber erkenne, wenn ich sie lese).


> ...
>>>     find Public -type d -exec chmod g+s {}\;
>                                               ^ - da fehlt ein"space".
>> [root@alarm joerg]# find Public -type d -exec chmod g+s {}\;
>> find: missing argument to `-exec'
>
> Und daher kommt die Fehlermeldung.
>

Gleiche Fehlermeldung mit Space, daran liegt es nicht.


>> Da muss ich mich wohl erst mal einlesen :-)
>
> Aber "find" ist durchaus ein bisserl "einlesen" wert.
>

Ja. Derzeit gibt es bei mir mit Linux den Baedecker-Effekt, ueberall 
entdecke ich was neues. Z.B. wollte ich erstmal einen Snapshot machen, 
bevor ich was am OS zerschiesse. Bei Lesen habe ich zur Freude 
festgestellt, dass MX-Linux bereits snapshot inklusive einem GUI 
eingebaut hat. Bleibt also nur noch dieses Arch Linux NAS Kaestchen, wo 
ich den USB Stick abziehen und kopieren kann. Dabei muss ich aber 
sicherstellen, dass Attribute verbleiben und auch wirklich alle Files 
kopiert werden. Kommt alles, dauert bei Anfaengern aber.


>> Vielleicht ginge
>>
>> chmod g+s /mnt/SD/Public
>
> Sicher geht das, wenn Du das so haben willst.
>

Genau das weiss ich eben noch nicht und es ist besser, erst zu lesen und 
dann zu probieen, nicht umgekehrt.


>> aber das muss ich erst nachlesen, ehe ich mir das ganze OS des NAS
>> zerschiesse.
>
> Also noch kein "Wizard Of Oz^HS"...
>

?

> ...
>> Ist wahrscheinlich besser, aber soweit bin ich noch nicht. Ich wollte
>> die Sache erstmal verstehen und spaeter versuchen, daran zu schrauben.
>
> Du _könntest_ auch mal Empfehlungen (an unkritischen Beispielen)
> ausprobieren und annehmen, wenn sie Dir taugen.


Genau das tat ich hier, lief aber (bisher) nicht. Doch das Herausfinden 
des Grundes hat einen Lerneffekt, muss ich durch.


>                                     ... Später verstehen wollen ist
> ja in Ordnung, aber dann "erstmal" stattdessen selbergezimmerte Krücken
> dafür zu benutzen ist halt durchaus "suboptimal". Man könnte aus Deiner
> Reaktion fast schließen mögen, Du littest unter dem "NIH-Syndrom"...
>

Definitiv nicht, schon gar nicht bei Linux. Da werde ich auf lange Sicht 
nichts selbst erfinden koennen, vielleicht auch nie und das ist ok.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111574

Hallo Joerg,

Du schriebst am Tue, 04 Aug 2020 12:47:30 -0700:

> > Sag'mal, liest Du eigentlich nur die Antworten auf Deine Fragen?
> > Genau zu dem Thema hat Helmut Waitzmann vor nicht langer Zeit eine
> > längere Abhandlung (so könnte man das nennen) geschrieben. Der Frager
...
> Ich suche vor Postings hier schon intensiv, allerdings nicht in 
> deutscher Sprache, weil die nicht mehr so gut sitzt bei mir und ich auch 

Dann merk' Dir mal Helmuts Namen, den solltest Du dann in Deine Sucherei
einbeziehen, auch wenn er auf deutsch schreibt.

> deutsche Computer-Ausdruecke nicht kenne (aber erkenne, wenn ich sie
> lese).

Na, hoffentlich auch richtig.

> > ...  
> >>>     find Public -type d -exec chmod g+s {}\;  
> >                                               ^ - da fehlt ein"space".  
...
> > Und daher kommt die Fehlermeldung.
> 
> Gleiche Fehlermeldung mit Space, daran liegt es nicht.

Fragr sich noch, _wo_ "space" - vor oder nach dem Backslash? Er muß _davor_
rein, weil er den ";" für die Shell "maskiert", so daß ihn das "find"
kriegt. und "find" will halt wohl eine Trennung zwischen dem Klammerpaar
(das als Ersetzungszeichen für den jeweiligen Dateinamen steht) und dem
abschließenden ";" sehen (weiß ich nicht siche, weil ich das sowieso
"gewohnheitsmäßig" so mache).

...
> >> aber das muss ich erst nachlesen, ehe ich mir das ganze OS des NAS
> >> zerschiesse.  
> >
> > Also noch kein "Wizard Of Oz^HS"...
> 
> ?

Wie, kennste nich? "Wizard Of Oz" ist ein schon älterer Kinofilm,
allerdings aus der "Tränendrüsenecke", nix "harter Western" oder so.
Basiert AFAIK irgendwie auf Erzählungen eines englischen Mathematikers.

> > ...  
> >> Ist wahrscheinlich besser, aber soweit bin ich noch nicht. Ich wollte
> >> die Sache erstmal verstehen und spaeter versuchen, daran zu
> >> schrauben.  
> >
> > Du _könntest_ auch mal Empfehlungen (an unkritischen Beispielen)
> > ausprobieren und annehmen, wenn sie Dir taugen.  
> 
> Genau das tat ich hier, lief aber (bisher) nicht. Doch das Herausfinden 

Schaut "von außen" allerdings nicht so aus, sondern so, daß Du dann, wenn
Du eine, auch noch getestete, Vorlage erhaltst, immer mit "wollte die Sache
erstmal verstehen und spaeter versuchen" abwiegelst, aber zufällig im
internet aufgefundene "Lösungen" völlig kritiklos ausprobierst und dann
jammernd daherkommst, wenn Du damit auf die Nase geflogen bist.

> des Grundes hat einen Lerneffekt, muss ich durch.

Dann mach'mal, kriegst auch sicher keine weiteren Hilfen.

...
> > Reaktion fast schließen mögen, Du littest unter dem "NIH-Syndrom"...
> 
> Definitiv nicht, schon gar nicht bei Linux. Da werde ich auf lange Sicht 
> nichts selbst erfinden koennen, vielleicht auch nie und das ist ok.

Das hat auch nichts mit _er_finden zu tun, hier ist auch eigenständiges
Finden von Lösungen schon enthalten.
Verglichen mit Deiner arbeit: Linux ist Werkzeug und Material, der Aufbau
einer funktionierenden Einrichtung ist die Entwicklungsarbeit.

-- 
-- 
(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]

#111577

On 2020-08-05 12:07, Sieghard Schicktanz wrote:
> Hallo Joerg,
>
> Du schriebst am Tue, 04 Aug 2020 12:47:30 -0700:
>
>>> Sag'mal, liest Du eigentlich nur die Antworten auf Deine Fragen?
>>> Genau zu dem Thema hat Helmut Waitzmann vor nicht langer Zeit eine
>>> längere Abhandlung (so könnte man das nennen) geschrieben. Der Frager
> ...
>> Ich suche vor Postings hier schon intensiv, allerdings nicht in
>> deutscher Sprache, weil die nicht mehr so gut sitzt bei mir und ich auch
>
> Dann merk' Dir mal Helmuts Namen, den solltest Du dann in Deine Sucherei
> einbeziehen, auch wenn er auf deutsch schreibt.
>

Ja, er hat mir auch mal per PM geschrieben, als Usenet nicht ging. Fand 
ich sehr nett.


>> deutsche Computer-Ausdruecke nicht kenne (aber erkenne, wenn ich sie
>> lese).
>
> Na, hoffentlich auch richtig.
>
>>> ...
>>>>>      find Public -type d -exec chmod g+s {}\;
>>>                                                ^ - da fehlt ein"space".
> ...
>>> Und daher kommt die Fehlermeldung.
>>
>> Gleiche Fehlermeldung mit Space, daran liegt es nicht.
>
> Fragr sich noch, _wo_ "space" - vor oder nach dem Backslash? Er muß _davor_
> rein, weil er den ";" für die Shell "maskiert", so daß ihn das "find"
> kriegt. und "find" will halt wohl eine Trennung zwischen dem Klammerpaar
> (das als Ersetzungszeichen für den jeweiligen Dateinamen steht) und dem
> abschließenden ";" sehen (weiß ich nicht siche, weil ich das sowieso
> "gewohnheitsmäßig" so mache).
>

Scheint vor dem Schraegstrich zu sein, das habe ich im Internet manchmal 
gesehen:

https://stackoverflow.com/questions/49470932/generate-entity-in-symfony-4-methods/49471205

So lief es dann bei mir ohne Fehlermeldung:

find /mnt/SD/Public -type d -exec chmod g+s {} \;

Allerdings hat es die Rechte "Read/Write by Others" nicht durchgereicht, 
funktioniert irgendwie nicht.


> ...
>>>> aber das muss ich erst nachlesen, ehe ich mir das ganze OS des NAS
>>>> zerschiesse.
>>>
>>> Also noch kein "Wizard Of Oz^HS"...
>>
>> ?
>
> Wie, kennste nich? "Wizard Of Oz" ist ein schon älterer Kinofilm,
> allerdings aus der "Tränendrüsenecke", nix "harter Western" oder so.
> Basiert AFAIK irgendwie auf Erzählungen eines englischen Mathematikers.
>

Ich sehe nicht viele Filme, und auch wenig am Fernseher.


>>> ...
>>>> Ist wahrscheinlich besser, aber soweit bin ich noch nicht. Ich wollte
>>>> die Sache erstmal verstehen und spaeter versuchen, daran zu
>>>> schrauben.
>>>
>>> Du _könntest_ auch mal Empfehlungen (an unkritischen Beispielen)
>>> ausprobieren und annehmen, wenn sie Dir taugen.
>>
>> Genau das tat ich hier, lief aber (bisher) nicht. Doch das Herausfinden
>
> Schaut "von außen" allerdings nicht so aus, sondern so, daß Du dann, wenn
> Du eine, auch noch getestete, Vorlage erhaltst, immer mit "wollte die Sache
> erstmal verstehen und spaeter versuchen" abwiegelst, aber zufällig im
> internet aufgefundene "Lösungen" völlig kritiklos ausprobierst und dann
> jammernd daherkommst, wenn Du damit auf die Nase geflogen bist.
>

Die probiere ich nicht kritiklos aus und oft ist es so, dass es einfach 
nicht funktioniert. Etwa bei Methoden, wie eine BCM4312 WLAN Karte 
"definitiv" ans Laufen kommen sollte. Habe ich am Ende durch eine Intel 
5300 ersetzt, einem Tipp hier aus der NG folgend.


>> des Grundes hat einen Lerneffekt, muss ich durch.
>
> Dann mach'mal, kriegst auch sicher keine weiteren Hilfen.
>

Brauche ich auch erstmal nicht, Marcel hat ja die Loesung aufgezeigt. 
Sie funktioniert zwar noch nicht, aber das wird schon irgendwie.


> ...
>>> Reaktion fast schließen mögen, Du littest unter dem "NIH-Syndrom"...
>>
>> Definitiv nicht, schon gar nicht bei Linux. Da werde ich auf lange Sicht
>> nichts selbst erfinden koennen, vielleicht auch nie und das ist ok.
>
> Das hat auch nichts mit _er_finden zu tun, hier ist auch eigenständiges
> Finden von Lösungen schon enthalten.
> Verglichen mit Deiner arbeit: Linux ist Werkzeug und Material, der Aufbau
> einer funktionierenden Einrichtung ist die Entwicklungsarbeit.
>

Oder man lebt mit dem, was die Distro bietet. Bei MX-Linux ist das gar 
nicht schlecht. Als ich gestern vor einem Test alles wegsichern wollte, 
stellte ich ueberrascht fest, dass dort bereits snapshot eingebaut ist. 
Mit GUI und es legt einem eine .iso der eigene Version in /home ab, mit 
der man notfalls einen bootfaehigen USB Stick erzeugen kann. Das ist 
schon luxurioes.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111581

On Wed, 05 Aug 2020 23:35:05 Joerg wrote:
> So lief es dann bei mir ohne Fehlermeldung:
> 
> find /mnt/SD/Public -type d -exec chmod g+s {} \;
> 
> Allerdings hat es die Rechte "Read/Write by Others" nicht durchgereicht, 
> funktioniert irgendwie nicht.

Die Rechte "Read/Write by Others" werden von diesem Befehl ja auch
gar nicht berührt, wer sollte die durchreichen?

#v+
find /mnt/SD/Public -type d -exec chmod g+s,o+rw {} \;
#v-

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Genuss wo noch nie ein Mensch gewesen: Stefan!
(Sloganizer)

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

#111583

Am Thu, 06 Aug 2020 06:07:06 +0000 schrieb Stefan Froehlich:

> On Wed, 05 Aug 2020 23:35:05 Joerg wrote:
>> So lief es dann bei mir ohne Fehlermeldung:
>> 
>> find /mnt/SD/Public -type d -exec chmod g+s {} \;
>> 
>> Allerdings hat es die Rechte "Read/Write by Others" nicht
>> durchgereicht,
>> funktioniert irgendwie nicht.
> 
> Die Rechte "Read/Write by Others" werden von diesem Befehl ja auch gar
> nicht berührt, wer sollte die durchreichen?
> 
> #v+
> find /mnt/SD/Public -type d -exec chmod g+s,o+rw {} \;
> #v-

Zeigt schön, daß der Ansatz eine Sackgasse ist.
Wo ist der Vorteil wenn ein neu angelegtes Verzeichnis in 
einer Gruppe ist, für die man Rechte als other braucht?

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

#111589

On Thu, 06 Aug 2020 09:16:15 Thomas Noll wrote:
> Am Thu, 06 Aug 2020 06:07:06 +0000 schrieb Stefan Froehlich:
> > On Wed, 05 Aug 2020 23:35:05 Joerg wrote:
> >> So lief es dann bei mir ohne Fehlermeldung:
> >> 
> >> find /mnt/SD/Public -type d -exec chmod g+s {} \;

> >> Allerdings hat es die Rechte "Read/Write by Others" nicht
> >> durchgereicht, funktioniert irgendwie nicht.

> > Die Rechte "Read/Write by Others" werden von diesem Befehl ja auch gar
> > nicht berührt, wer sollte die durchreichen?
> > 
> > #v+
> > find /mnt/SD/Public -type d -exec chmod g+s,o+rw {} \;
> > #v-
 
> Zeigt schön, daß der Ansatz eine Sackgasse ist.

Zeigt vor allem sehr schön, dass ich nicht nur einzelne Postings
lesen sollte, sondern den gesamten Thread. Die Antwort mag zwar
wörtlich betrachtet korrekt sein, geht aber völlig am Problem vorbei
:-)

> Wo ist der Vorteil wenn ein neu angelegtes Verzeichnis in einer
> Gruppe ist, für die man Rechte als other braucht?
 
Ack. Womit wir dann offenbar doch wieder bei setfacl(1) wären.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Perfektum fantasticum! Stefan, wenn der kleine Hunger plagt!
(Sloganizer)

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

#111607

On 2020-08-06 05:28, Stefan Froehlich wrote:
> On Thu, 06 Aug 2020 09:16:15 Thomas Noll wrote:

[...]


> > Wo ist der Vorteil wenn ein neu angelegtes Verzeichnis in einer
>> Gruppe ist, für die man Rechte als other braucht?
>
> Ack. Womit wir dann offenbar doch wieder bei setfacl(1) wären.
>

Wobei das fuer einen Anfaenger echt schwerer Tobak ist und wie man das 
fuer neu zu erstellende Directories regelt, kriege ich irgendwie nicht raus:

https://linux.die.net/man/1/setfacl

Schoen waere, wenn ich das komplette Rechte-Gehampel fuer den /Public 
Bereich rauswerfen koennte. Denn Samba schraenkt das ja nochmals passend 
ein und dann gaebe es keinen Aerger mit neu erstellten Directories mehr. 
FAT Formatierung geht da nicht, weil schonmal Files ueber 4GB 
draufkommen. exFAT kann mit Linux m.W. Aerger geben. Oder NTFS? Egal, 
ich lasse das erstmal so wie es ist. Nicht perfekt, aber wenigstens 
kommt man mit Klimmzuegen an die Files.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111609

On Fri, 07 Aug 2020 23:20:44 Joerg wrote:
> On 2020-08-06 05:28, Stefan Froehlich wrote:
> > On Thu, 06 Aug 2020 09:16:15 Thomas Noll wrote:
> [...]
> >> Wo ist der Vorteil wenn ein neu angelegtes Verzeichnis in einer
> >> Gruppe ist, für die man Rechte als other braucht?

> > Ack. Womit wir dann offenbar doch wieder bei setfacl(1) wären.

> Wobei das fuer einen Anfaenger echt schwerer Tobak ist [...]

Ich empfehle, die Finger davon zu lassen, wann immer es möglich ist.
Man kann fraglos ganz tolle Dinge damit anstellen, aber sobald das
Setup deutlich komplexer wird, als es auch ohne ALCs möglich gewesen
wäre, tendiere ich dazu, die Übersicht zu verlieren.

und wie man
> das fuer neu zu erstellende Directories regelt, kriege ich
> irgendwie nicht raus:
> 
> https://linux.die.net/man/1/setfacl

acl(5) erklärt das in "OBJECT CREATION AND DEFAULT ACLs"; im
Wesentlichen legen die default-Regeln fest, wie die Zugriffsregeln
des neu erstellten Files oder Verzeichnisses aussehen.

> Schoen waere, wenn ich das komplette Rechte-Gehampel fuer den
> /Public Bereich rauswerfen koennte. Denn Samba schraenkt das ja
> nochmals passend ein und dann gaebe es keinen Aerger mit neu
> erstellten Directories mehr. 

Samba und Berechtigungen ist so eine Geschichte. Mir fehlt im
Anlassfall immer die Zeit, mich damit auseinanderzusetzen, aber
Windows bzw. die Applikation spricht da auch gerne ein Wort mit
(abhängig davon, ob es eine Datei neu erstellt und danach das
Original löscht, ob es eine Kopie erstellt, oder ob einfach direkt
die bestehende Datei bearbeitet wird).

Andererseits ist eine fein granulierte Rechtevergabe unter Windows
um keinen Deut einfacher oder übersichtlicher - komplexe Probleme
lassen sich halt nur selten einfach lösen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die schrecklichste Verführung der Nacht!
(Sloganizer)

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

#111616

On 2020-08-08 00:09, Stefan Froehlich wrote:
> On Fri, 07 Aug 2020 23:20:44 Joerg wrote:
>> On 2020-08-06 05:28, Stefan Froehlich wrote:
>>> On Thu, 06 Aug 2020 09:16:15 Thomas Noll wrote:
>> [...]
>>>> Wo ist der Vorteil wenn ein neu angelegtes Verzeichnis in einer
>>>> Gruppe ist, für die man Rechte als other braucht?
>
>>> Ack. Womit wir dann offenbar doch wieder bei setfacl(1) wären.
>
>> Wobei das fuer einen Anfaenger echt schwerer Tobak ist [...]
>
> Ich empfehle, die Finger davon zu lassen, wann immer es möglich ist.
> Man kann fraglos ganz tolle Dinge damit anstellen, aber sobald das
> Setup deutlich komplexer wird, als es auch ohne ALCs möglich gewesen
> wäre, tendiere ich dazu, die Übersicht zu verlieren.
>

Ich werde davon auch erstmal die Finger lassen, ist zu heiss.


> und wie man
>> das fuer neu zu erstellende Directories regelt, kriege ich
>> irgendwie nicht raus:
>>
>> https://linux.die.net/man/1/setfacl
>
> acl(5) erklärt das in "OBJECT CREATION AND DEFAULT ACLs"; im
> Wesentlichen legen die default-Regeln fest, wie die Zugriffsregeln
> des neu erstellten Files oder Verzeichnisses aussehen.
>

Sicher geht das irgendwie. Das schoene in Linux ist ja, dass man fast 
ueberall ran kann. Aber nicht fuer Anfaenger.


>> Schoen waere, wenn ich das komplette Rechte-Gehampel fuer den
>> /Public Bereich rauswerfen koennte. Denn Samba schraenkt das ja
>> nochmals passend ein und dann gaebe es keinen Aerger mit neu
>> erstellten Directories mehr.
>
> Samba und Berechtigungen ist so eine Geschichte. Mir fehlt im
> Anlassfall immer die Zeit, mich damit auseinanderzusetzen, aber
> Windows bzw. die Applikation spricht da auch gerne ein Wort mit
> (abhängig davon, ob es eine Datei neu erstellt und danach das
> Original löscht, ob es eine Kopie erstellt, oder ob einfach direkt
> die bestehende Datei bearbeitet wird).
>

Ich habe es mit Linux probiert und auch im Windows Boot. Es scheint, 
also ob auch nach g+s die Rechte neu erstellter Verzeichniss so gesetzt 
werden wie in umask festgelegt.


> Andererseits ist eine fein granulierte Rechtevergabe unter Windows
> um keinen Deut einfacher oder übersichtlicher - komplexe Probleme
> lassen sich halt nur selten einfach lösen.
>

Das lief eigentlich immer sauber. An die Geschaeftsdaten kam nur ich, 
waehrend das ganze "Public" Verzeichnis mit allen Unterverzeichnissen 
allgemein zugaenglich war. Sehr praktisch, wenn mal Besuch hier war. 
Nach dem Abgesang von Windows 7 musste das aber begraben werden. Alles 
hat mal ein Ende und irgendwann kriege ich das auch mit Linux hin.

Eine moegliche Loesung koennte umask sein. Ich haben noch einen zweiten 
Pogoplug, den ich hacken koennte. So koennte einer restriktive Rechte 
haben und der andere offen sein. Die nuckeln ja nur jeweils ein Watt.

Schoen war das beim Western Digital MyBook World geloest. Es lief mit 
Linux, hatte ein Web Browser Interface und man konnte darueber Rechte 
festlegen. Die wurden auch an neue Unterverzeichnisse durchgereicht, 
sofern man das nicht anders festlegte. Doch die Kiste blieb eines Tages 
final mit Hardwareschaden liegen und ich weiss nicht, wie sie die 
Rechtevergabe geloest haben. Ob webmin das koennte, weiss ich auch nicht 
und da haben Leute gesagt, man solle es eh nicht mehr benutzen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#111626

On Sat, 08 Aug 2020 19:01:38 Joerg wrote:
> On 2020-08-08 00:09, Stefan Froehlich wrote:
> > On Fri, 07 Aug 2020 23:20:44 Joerg wrote:
> >> On 2020-08-06 05:28, Stefan Froehlich wrote:
> > Ich empfehle, die Finger [von setfacl] zu lassen, wann immer es
> > möglich ist.  Man kann fraglos ganz tolle Dinge damit anstellen,
> > aber sobald das Setup deutlich komplexer wird, als es auch ohne
> > ALCs möglich gewesen wäre, tendiere ich dazu, die Übersicht zu
> > verlieren.

> Ich werde davon auch erstmal die Finger lassen, ist zu heiss.

Auf Datenordner angewendet kann man damit wenigstens nichts
irreparalbes anstellen. Und wenn man spezielle Anforderungen hat,
kommt man ohnehin nicht darum herum.
 
> > Andererseits ist eine fein granulierte Rechtevergabe unter
> > Windows um keinen Deut einfacher oder übersichtlicher - komplexe
> > Probleme lassen sich halt nur selten einfach lösen.

> Das lief eigentlich immer sauber. An die Geschaeftsdaten kam nur
> ich, waehrend das ganze "Public" Verzeichnis mit allen
> Unterverzeichnissen allgemein zugaenglich war. Sehr praktisch,
> wenn mal Besuch hier war.

*Das* würde ich ja mit zwei getrennten Shares lösen, von denen die
eine nur für Mitglieder von @business benutzbar ist. Dann sind die
Berechtigungen für Verzeichnisse und Files nicht mehr so dramatisch
wichtig.

Ich hatte eher so Konfigurationen im Hinterkopf, wo ein Verzeichnis
für den Besitzer und die Mitglieder von drei unterschiedlichen
Gruppen lesbar, aber nur für eine dieser Gruppen beschreibbar sein
soll, das auch für darin neu erstellte Dateien zu gelten hat, aber
eine bereits bestehende Datei zwar jeder lesen, aber nur der
Besitzer ändern darf.

Bekommt man immer noch hin, aber zumindestens ich kann fix davon
ausgehen, dass ich bei Existenz mehrerer solcher Anforderungen
innerhalb einer Share über kurz oder lang die Übersicht verliere,
wer wo was darf - und die Lesbarkeit auf der cli ist halt auch nur
bedingt gut. Benutzt der Besitzer des Verzeichnisses dann auch noch
ausnahmsweise einmal Software, die die Datei nicht zum Schreiben
öffnet, sondern sie unter neuem Namen erstellt, danach das Original
löscht und die neue Datei umbenennt, hast Du verloren (weil Du das
erst irgendwann merkst, wenn es ein Problem gibt).

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - deiner musiziert beschissener und auch nicht gebissener.
(Sloganizer)

[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