Re: samba4 unter ZFS

Peter Ross wrote:
> On Fri, 27 Sep 2013, Oliver Fromme wrote:
> > Die Library-Funktion getvfsbyname() ist nichts weiter als
> > ein Wrapper für diesen sysctl. Den sysctl kann jeder
> > unprivilegierte Benutzer lesen, auch in einem Jail.
> >
> > Bisher hat das noch niemanden gestört, aber wenn Du meinst,
> > dass das eine sensitive Information ist, kannst Du einen PR
> > aufmachen. Ich nehme an, dass es durchaus nicht unsinnig
> > wäre, dem sysctl einen Jail-Check zu verpassen, so dass in
> > einem Jail als refcount immer 0 geliefert wird. (Man müsste
> > in src/sys/kern/vfs_subr.c in den Funktionen vfsconf2x und
> > vfsconf2x32 einen prison_check() einbauen.) Wenn Du den PR
> > nicht aufmachst, mach ich ihn auf. :-)
>
> Wobei "0" waere mir auch nicht recht.. z.b. wuesste dann "Dein" Skript
> nicht, das da ZFS benutzt wird. Es sollte also mit dem Output des "df"
> ("1") antworten.

Naja, entweder, Du möchtest die Information in einem Jail
bereitstellen oder nicht. Wenn nicht, dann kann sie auch
mein Skript nicht ermitteln. Wenn das Skript funktionieren
soll, dann können auch andere die Information lesen.

Im Falle von statfs(2) kann der Admin per Jail-Parameter
entscheiden, ob und welche Informationen im Jail verf[gbar
sein sollen. Siehe "enforce_statfs" in der jail(8)-Manpage.

Etwas Ähnliches könnte man für den sysctl vfs.conflist
implementieren, z.B. "enforce_vfsconf": Wenn 0, werden
alle Informationen geliefert (original refcount), wenn 1,
wird nur 1 oder 0 geliefert (filesystem vorhanden oder
nicht vorhanden), und wenn 2, gibt es immer EPERM.

> Ich weiss nicht, wie sensitiv das ist. Es sagt mir lediglich: Da sind noch
> 163 andere Filesysteme, vielleicht lohnt es sich hier, mehr
> "rumzuhacken"..

Über Sensitivität hat jeder Admin seine eigenen Ansichten.
Die Jail-Implementation sollte die Mechanismen zur Verfügung
stellen, die es jedem Admin erlauben, seine eigenen Ansichten
zu verwirklichen.

Rein prinzipiell kann man auch argumentieren, dass es möglich
sein sollte, ein Jail so zu konfigurieren, dass _keinerlei_
Informationen darin verfügbar sind, die sich auf die Umgebung
außerhalb des Jails beziehen.

Auch eine unscheinbare Information kann weitreichende Folgen
haben, ohne dass man es auf Anhieb erkennt. Dass z.B. die
Stromaufnahme eines Crypto-Chips (oder auch nur dessen
Wärmeentwicklung) Rückschlüsse auf die Verschlüsselung
zulässt, darauf musste auch erstmal jemand kommen.

> Wenn ich df richtig aufdrösele, nutzt das die libc-Funktion getmntinfo,
> und das wiederum geht auf kern_getfsstat in ./kern/vfs_syscalls.c zurück
> und in der Funktion sehe ich ein if (prison_canseemount..)
> [...]
> aber wenn ich Dich richtig verstehe, sollten die Funktionen vfsconf2x und
> vfsconf2x32 ebenfalls einen solchen Check bekommen?

Ja, im prinzip.

> Für mich sieht es so aus, als wenn schon mal jemand drüber nachgedacht hat
> ("besser wir verstecken die Mountinformationen vor den Jails"), dann aber
> das in.. sysctl_vfs_conflist(?) vergessen hat?

Der "jemand" war ich, vor 12 bzw. 10 Jahren. :-)
Siehe PR kern/26740 und kern/47586. Das war damals noch für
4.x bzw 5-current; heute sieht der Code etwas anders aus.

Und zum Thema "vergessen": Die beiden Dinge haben ja erstmal
nichts miteinander zu tun. Bei statfs(2) geht es um Mounts,
bei vfs.conflist geht es um FS-Module im Kernel. Letzteres
wurd auch erst Ende 2002 eingeführt; ich hatte das bei meinen
o.g. Patches noch nicht so auf dem Radar.

> Das müßte dann in dem Abschnitt
>
> TAILQ_FOREACH(vfsp, &vfsconf, vfc_list) {
> bzero(&xvfsp, sizeof(xvfsp));
> vfsconf2x(vfsp, &xvfsp);
> error = SYSCTL_OUT(req, &xvfsp, sizeof xvfsp);
> if (error)
> break;
> }
>
> äquivalent to dem in kern_getfsstat ein Test eingefügt werden.

Hm, woher ist denn der Abschnitt? Ich würde es in den
Funktionen vfsconf2x() und vfsconf2x32() machen.

> Ich versuche immer noch, das samba-tool Python-Skript zu fixen, ist es
> okay, Deine Zeilen dort (modifiziert, dem Zweck entsprechen, einzufügen?
> Es gibt mir einen Teil der Idee, wie das zu machen ist.

Ja, sicher, kein Problem.

> Das ist falsch, ich habe das beim ersten Lesen als eine Iteration
> über Filesysteme gesehen, es ist aber eine Liste von Informationen per
> Filesystyemtyp.
>
> Wenn man wirklich wissen will, welche Filesysteme das Jail sehen kann, muß
> man dann doch durch alle Mounts durch..

Ah, jetzt verstehe ich, worauf Du hinauswolltest. Also, den
Aufwand würde ich nicht treiben, sondern pauschal festlegen:
Das Jail darf den "echten" refcount sehen, oder nur 0/1, oder
gar nichts.

> Wenn man das nicht macht: Statt "0" als Refcount sollte dann doch eher ein
> "Not permitted" für den syscall kommen, sonst ist das eher verwirrend?

Ja, entweder EPERM, oder der sysctl liefert einfach überhaupt
keine Daten (eine leere Liste), so als ob der Kernel keine
FS-Module enthielte. Letzteres hätte den Vorteil, dass man
getfsbyname() nicht anpassen müsste. Es würde dann einfach
immer ENOENT liefern. Und auch lsvfs(1) würde sich konsistent
verhalten.

> Dann müßte Dein Skript aber auch auf was anderem aufbauen, um mir im Jail
> sagen zu können, ob ZFS darin eine Rolle spielt.

Ziel des Patches ist doch, dass im Jail diese Informatione
gerade _nicht_ verfügbar ist. Wenn man auf etwas anderem
aufbauen könnte, dann müsste man das auch wegpatchen. :-)
Das Skript funktioniert dann nur noch außerhalb von Jails.

> Eigentlich sollte im Falle von Samba der Check des Filesystemtyps pro
> Share stattfinden, denn ich kann ja durchaus einen Mix von Filesystemen
> haben.. (Ich will da lieber nicht weiter drüber nachdenken;-)

Den Absatz habe ich nicht ganz verstanden, um ehrlich zu sein.

> Ich habe aber ein anderes Problem, was mit meiner Unbedarftheit in
> Richtung Python und Samba zu tun hat: das Laden von Modulen.
>
> Samba hat ladbare Module und eines ist zfsacl.so.
>
> Ich finde:
>
> % pkg query %Fp samba4 | grep zfs
> /usr/local/lib/shared-modules/vfs/zfsacl.so
>
> aber:
>
> % pkg query %Fp samba4 | grep xattr | grep '.so'
> /usr/local/lib/python2.7/site-packages/samba/dcerpc/xattr.so
> /usr/local/lib/python2.7/site-packages/samba/xattr_native.so
> /usr/local/lib/python2.7/site-packages/samba/xattr_tdb.so
> /usr/local/lib/samba/libxattr_tdb.so
> /usr/local/lib/shared-modules/vfs/acl_xattr.so
> /usr/local/lib/shared-modules/vfs/streams_xattr.so
> /usr/local/lib/shared-modules/vfs/xattr_tdb.so
>
> Wenn ich es richtig verstehe, wird mit
> "import samba.xattr_native" in samba/ntacl.py
> /usr/local/lib/python2.7/site-packages/samba/xattr_native.so
> geladen.
>
> Ist /usr/local/lib/python2.7/site-packages/samba/xattr_native.so)
> ein Wrapper um die "System-Bibliotheken" unter
> /usr/local/lib/shared-modules/vfs ?)
>
> D.h. muß erst noch eine solcher "Python-Wrapper" um zfsacl.so gebaut
> werden, damit ich es in einem Python-Skript (und nicht nur im s3fs-Binary)
> benutzen kann?

Das kann ich leider nicht beantworten. Momentan habe ich
gerade kein Samba4 unter meinen Fingern, um mir das näher
anzusehen. Auf meiner Kiste hier verwende ich noch Samba3.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"I learned Java 3 years before Python.  It was my language of
choice.  It took me two weekends with Python before I was more
productive with it than with Java." -- Anthony Roberts
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message