Pár dotazů k sshfs: práva, allow other/root, chroot

[mikesznovu]

Mám pár dotazů k sshfs (fuse):
-Provozuji to s ChrootDirectory. To samo o sobě poněkud zesložiťuje proces. Cesta musí být chmod +rx a -w.
Například
-Proč příkaz ls mi v mountnuté složce i podadresářích  hlásí nesprávná owner a group (místo jména čísla 1005 1002). Jako rozumím, že terminál(pc) nezná uživatele 1002 a 1005, proto se nemá co vypsat. - mám  pocit že do je dál způsobuje
 hlubší problémy dál
-Hodně záleží na nastavení práv složky chroot. Nechápu proč musí mít aspoň OTHER:eXecute
 právo, jinak se do ni na terminálu nedostanu. Klíčové je proč other, když tem přeci by to měl být uživatel User(owner), když jsem se k sshfs přihlašoval jako uživatel existující na serveru(a ten je vlastník té složky s právy rwx)
-(navazuje) Lze tedy nějak docílit aby to fungovalo i bez práv O:RX ?  (r není tak důležité, pokud se používá jako pracovní složka podsložka toho chrootu/připojeného adresáře. r omezuje jen výpis obsahu toho adresáře. Ale x zatrhne přístup uplně )
- Proč mi terminál hlásí , když jsem se připojoval na terminálu přes sudo sshfs (následně bez sud/a/o/u)

Kód: [Vybrat]

klient@terminal:~/tmp $  ls -l
ls: nelze přistoupit k 'bla': Operace zamítnuta
celkem 16
d????????? ? ?  ?     ?            ? bla

- K čemu mi jsou volby na terminálu fuse -o allow_root a -o allow_other. Co s čím se kontroluje?
-pomůže něčemu volba idmap?
Článek na root.cz zavádíme omezení v ssh jsem četl.

[Reklama]

[mikesznovu]

a jaktože když root na server vytvoří soubor (má práva) -rw-r--r-- 1 root root 3 Jan 22 00:12 /datadisk/upl/chf/rr.txt, tak ho klidně lokální cucák klient na  terminálu přihlášený  jako vzdálený cucák uph  přihlášený jako uph může smazat)
(up je chroot drwxr-xr-x 3 root root), chf je zapisovatelný adresář (drwxr-xr-x 3 uph uph 65 Jan 22 00:18 chf)

uph je jméno uživatele na serveru.
mount je  sshfs "uph@rIP:" -p 22  lokalni.mount.point
kdežto uživatel uph na serveru obsah /datadisk ani nevidí jelikož nemá O:X

[Jose D]

a jaktože když root na server vytvoří soubor (má práva) -rw-r--r-- 1 root root 3 Jan 22 00:12 /datadisk/upl/chf/rr.txt, tak ho klidně lokální user klient na  terminálu přihlášený  jako vzdálený user uph  přihlášený jako uph může smazat)

co má za práva directory /datadisk/upl/chf

[Death Walker]

a jaktože když root na server vytvoří soubor (má práva) -rw-r--r-- 1 root root 3 Jan 22 00:12 /datadisk/upl/chf/rr.txt, tak ho klidně lokální cucák klient na  terminálu přihlášený  jako vzdálený cucák uph  přihlášený jako uph může smazat)
(up je chroot drwxr-xr-x 3 root root), chf je zapisovatelný adresář (drwxr-xr-x 3 uph uph 65 Jan 22 00:18 chf)

uph je jméno uživatele na serveru.
mount je  sshfs "uph@rIP:" -p 22  lokalni.mount.point
kdežto uživatel uph na serveru obsah /datadisk ani nevidí jelikož nemá O:X

Pretoze ma k tomu nastavene prava.

Ak to ma fungovat tak ze subor moze zmazat len vlastnik suboru, tak nadradeny adresar musi mat nastaveny sticky bit

[Petr Krčmář]

a jaktože když root na server vytvoří soubor (má práva) -rw-r--r-- 1 root root 3 Jan 22 00:12 /datadisk/upl/chf/rr.txt, tak ho klidně lokální cucák klient na  terminálu přihlášený  jako vzdálený cucák uph  přihlášený jako uph může smazat)

To nesouvisí s SSH, takhle fungují souborová práva v Linuxu (a dalších). Při mazání nezáleží na právech na souboru, ale záleží na nadřazeném adresáři. Adresář je totiž vlastně seznam souborů s odkazem na i-nody. Když v tomhle seznamu (v těle adresáře) ten soubor smažu, tak zmizí. Souborový systém se pak postará o to, že nereferencované soubory (i-nody) odstraní taky, protože se k nim uživatel stejně nemá jak dostat.

Takže platí, že soubory můžu mazat, pokud mám právo zapisovat do adresáře. Jak píše kolega nahoře, pokud to má být jinak, je třeba nastavit tomu adresáři sticky bit. Takhle se chová třeba /tmp, kam musejí mít právo zápisu všichni, ale nebylo by dobré, kdyby si tam taky mohli mazat soubory.

[Reklama]

[mikesznovu]

Aha, pak mi došlo, že owner adresáře  je vlastně ten, kdo může operovat se soubory a ne owner...

Pořád ale by mě zajímala ta nutnost práv xx4(xx5) na Chroot. Četl jsem to i na stackoverflow, manuály chrootu zmiňují podmínku 755.
A pak ten diskutovaný problém s právy other, že prý to bezpečnostně není v pořádku, že to může číst jiný uživatel.... A nebo to právě díky chrootu efektivně nehrozí? (Podobné vlákno https://forum.root.cz/index.php?topic=25718.msg364794#msg364794 )

Akorát  soubor z up/chf lze stále smazat: Znamená to že tohodle chování tedy v složce chf (vlastněné uph) nedocílím, Musí to být přímo v rootu nebo v systému cest vlastněné rootem?

Kód: [Vybrat]

a# ls -lR /datadisk

total 0
drwxr-xr-t 3 uph  root 20 J up (zkoušeno i bez/sticky na tento)


up
total 0
drwxrwx--T 5 uph uph 52 slozka
-rw-r--r-- 1 root root 3  rr-soubor-co-nejde-smazat

up/chf:
total 4
-rw-r--r-- 1 root root 3  rr-soubor-co-jde-smazat

chown root:root /datadisk/up/chf/rr-soubor-co-jde-smazat

Nebo to prostě je to špatné chápání, že i  root se nemá co divit, když zapisuje do adresáře, který patří někomu jinému a může ho smazat?

Prostě mi to chování oprávnění složky x soubory bylo neintuitivní. Schválně jsem si udělal složku vlastněnou rootem a v ní soubor vlastněný uphem.. zapisovat do něj šlo smazat ho ne. Musí se myslet ne jen na samotný soubor ale na adresář ve kterém leží...

Musí být nějaké oprávnění kaskádově (složky od /,/datadisk,/datadisk/slozka2) povolené, aby šel soubor smazat případně modifikovat? 

[Death Walker]

Aha, pak mi došlo, že owner adresáře  je vlastně ten, kdo může operovat se soubory a ne owner...

Pořád ale by mě zajímala ta nutnost práv xx4(xx5) na Chroot. Četl jsem to i na stackoverflow, manuály chrootu zmiňují podmínku 755.
A pak ten diskutovaný problém s právy other, že prý to bezpečnostně není v pořádku, že to může číst jiný uživatel.... A nebo to právě díky chrootu efektivně nehrozí? (Podobné vlákno https://forum.root.cz/index.php?topic=25718.msg364794#msg364794 )

Akorát  soubor z up/chf lze stále smazat: Znamená to že tohodle chování tedy v složce chf (vlastněné uph) nedocílím, Musí to být přímo v rootu nebo v systému cest vlastněné rootem?

Kód: [Vybrat]

a# ls -lR /datadisk

total 0
drwxr-xr-t 3 uph  root 20 J up (zkoušeno i bez/sticky na tento)


up
total 0
drwxrwx--T 5 uph uph 52 slozka
-rw-r--r-- 1 root root 3  rr-soubor-co-nejde-smazat

up/chf:
total 4
-rw-r--r-- 1 root root 3  rr-soubor-co-jde-smazat

chown root:root /datadisk/up/chf/rr-soubor-co-jde-smazat

Nebo to prostě je to špatné chápání, že i  root se nemá co divit, když zapisuje do adresáře, který patří někomu jinému a může ho smazat?

Prostě mi to chování oprávnění složky x soubory bylo neintuitivní. Schválně jsem si udělal složku vlastněnou rootem a v ní soubor vlastněný uphem.. zapisovat do něj šlo smazat ho ne. Musí se myslet ne jen na samotný soubor ale na adresář ve kterém leží...

Musí být nějaké oprávnění kaskádově (složky od /,/datadisk,/datadisk/slozka2) povolené, aby šel soubor smazat případně modifikovat?

Ten sticky bit musite mat nastaveny na adresari ktory ten subor priamo obsahuje. V linuxe sa opravnenie kaskadovo z nadradenych adresarov nededia. Ak je potreba nastavit na rovnake opravnenie aj pre podadresare tak sa zapne rekurzia, prepinac -R. Pri rekurzii pouzite radsej velke X, to ovplivni len adresare, male x by vam rekurzivne nastavilo aj obyc. subory ako spustitelne.

x na adresari znamena ze sa do neho mozete vnorit a pracovat v jeho kontexte. chroot znamena ze adresar ktory je pre chroot nastaveny sa javi ako korenovy (change root - chroot). Tj. cd .. je na nom nefunguje.

Ak potrebujete jemnejsie nastavenie prav, tak sa pozrite na selinux...

[Death Walker]

A pak ten diskutovaný problém s právy other, že prý to bezpečnostně není v pořádku, že to může číst jiný uživatel.... A nebo to právě díky chrootu efektivně nehrozí? (Podobné vlákno https://forum.root.cz/index.php?topic=25718.msg364794#msg364794 )

Este k tej bezpecnosti. Kazdy ma take opravnenia akemu date. Mozete nastavit opravnenia tak aby others nemali pravo na read. A pre uzivatelov ktory maju mat prava, vyuzijete to ze uzivatel moze byt clenom viacerych skupin. Rovnako ako aj skupiny mozu byt clenmi dalsich skupin. To aby sa subory a adresare vytvarali so skupinou ktoru ma nastaveny nadradeny adresar a nie s jeho primarnou skupinou dosiahnete pomocou setgid priznaku.

cize nejako takto:

Kód: [Vybrat]

# vytvori skupinu
groupadd sshfsusers

# nastavi skupinu pre subory
chgrp -R sshfsusers /datadisk/up

# nastavi setgid
chmod -R g+s /datadisk/up

# nepusti do adresara ostatnych
chmod -R o-r,o-w,o-x /datadisk/up

# pridame uzivatela fero do skupiny
usermod -a -G sshfsusers fero

# od teraz mozu /datadisk/up pouzivat uzivatelia v skupine sshfsusers a vlastnici, iny nie.

To je len priklad, konkretne riesenie musite vytvorit podla predstav, vyuzitim znalosti ktore si dostudujete.