Dotaz: Nejde ls

[Karel]

Zdravim,
dokaze mi nekdo vysvetlit, proc mi nejde udelat 'ls' pro adresar, kam bych mel mit podle me normalne pristup? (Linux, distribuce BackTrack 5R3)

root@bt:~# su bin
sh-4.1$ ls -l / | grep root$
drwxr-xr-x  24 root root  340 2013-03-13 16:27 root
sh-4.1$ ls -l /root
ls: cannot open directory /root: Permission denied

Odpovědi

[Karel]

root@bt:~# su bin

sh-4.1$ ls -l / | grep root$

drwxr-xr-x 24 root root 340 2013-03-13 16:27 root

sh-4.1$ ls -l /root ls: cannot open directory /root: Permission denied

[Milan Roubal]

to opravneni pro other bylo pridano rucne? protoze standartni Backtrack 5R3 zadne takove opravneni nema.

root@bt:~# ls -ld /root/
drwx------ 22 root root 4096 2012-08-14 17:13 /root/
root@bt:~# chmod 755 /root/
root@bt:~# ls -ld /root/
drwxr-xr-x 22 root root 4096 2012-08-14 17:13 /root/
root@bt:~# su bin
sh-4.1$ ls -al /root
total 128
drwxr-xr-x 22 root root 4096 2012-08-14 17:13 .
drwxr-xr-x 24 root root 4096 2012-08-10 18:51 ..
drwx------  2 root root 4096 2011-03-05 11:43 .aptitude
...
sh-4.1$ exit
root@bt:~# chmod 700 /root/
root@bt:~# ls -ld /root/
drwx------ 22 root root 4096 2012-08-14 17:13 /root/
root@bt:~# su bin
sh-4.1$ ls -l /root
ls: cannot open directory /root: Permission denied
sh-4.1$ 

[Kit]

Proč to cpeš na jeden řádek? Kdo to má luštit?

Však máš práva uživatele "bin". Ten do adresáře "/root" nemá přístup.

[Karel]

Za ten vypis na jednom radku se omlouvam, nevsim jsem si...

Jinak k veci: prava na adr. /root jsou rwxr-xr-x , cili "others" muzou cist. Ale ve skutecnosti nemuzou. Proc?

[Kit]

Aha, teď na to koukám. Možná je to blokováno v ACL.

[Karel]

which getfacl setfacl nic nevrati. A (nejsem si jist) mozna by zapnuti ACL bylo videt jako parametr v mount.

Nicmene pro uplnost:

root@bt:~# mount

aufs on / type aufs (rw)

none on /proc type proc (rw,noexec,nosuid,nodev)

none on /sys type sysfs (rw,noexec,nosuid,nodev)

none on /dev type devtmpfs (rw,mode=0755)

none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)

/dev/sdb1 on /cdrom type vfat (ro,noatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

/dev/loop0 on /rofs type squashfs (ro,noatime)

none on /sys/fs/fuse/connections type fusectl (rw)

none on /sys/kernel/debug type debugfs (rw)

none on /sys/kernel/security type securityfs (rw)

none on /dev/shm type tmpfs (rw,nosuid,nodev)

tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

none on /var/run type tmpfs (rw,nosuid,mode=0755)

none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)

none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)

[blondak]

A nemohl by to blokovat třeba selinux?

[Karel]

Neni pritomen adresar /etc/selinux.

A ani nic nenasel 'which sestatus getenforce setenforce'

[xkucf03]

Proč to cpeš na jeden řádek? Kdo to má luštit?

Opravil jsem to. Příště prosím autora, aby používat značku <pre/>

[NN]

Jak vypada 'bin' v /etc/passwd ?

[Šangala]

echo $SHELL
na uživatele bin a nejlépe na root-a:
grep -E "^bin" /etc/passwd
vypadá jak?

[Karel]

Vypis z /etc/passwd:

root:x:0:0:root:/root:/bin/bash
bin:x:2:2:bin:/bin:/bin/sh

[Karel]

to opravneni pro other bylo pridano rucne? protoze standartni Backtrack 5R3 zadne takove opravneni nema.

Toto vypada na spravnou stopu.
On ten Backtrack na soubory z distribuce (kde je /root opravdu rwx------) jeste primontuje uzivatelovy zmeny ze zvlastniho souboru /casper/local.squashfs. Zde mam par souboru v onom adreasari /root a bezdeky jsem tam i nechal prava pro /root na rwxr-xr-x. Ale asi to nefunguje spravne (nekouka na prava v mem zmenovem souboru). A nebo je to uplne jinak...

[Milan Roubal]

tak je to opravdu zavisle na te volbe persistent. Doma jsem to testoval na nainstalovanem systemu s ext3 a tam je chovani ocekavane.

Ted jsem to otestoval na nabootovane distribuci s aufs a chova se to presne podle popisu tohoto problemu. Pokud vsak vytvorim adresar /root2, ktery ma prava cteni pro other, pristup ziskavam. Bude se tedy pravdepodobne jednat o nejakou bezpecnostni vlastnost aufs. Pokud je tomu tak, tak je to dokonce mozna zrale na bugreport, protoze podle meho nazoru by melo selhat uz pridani opravneni pro cteni pro skupinu other na /root a nikoliv az samotne cteni obsahu adresare.

[Karel]

Jasne, /root2 je uz novy adresar, ktery nema s cim kolidovat v puvodnim filesystemu (mimochodem viditelnem v /rofs). Proto s nim neni problem.

V pripade adresare /root se kryje jeho puvodni "definice" (rwx------) s moji v local.squashfs (kde je navic rx pro skupinu a ostatni).

Jestli je to bug ci feature, me az tak neboli. Ja jsem chtel jen zjistit, proc se to chova jinak, nez jsem cekal. Takto mi to staci.

[darkenik]

je to normalne spravanie systemu,ktore mne tiez neraz sposobilo vrasky ak je povodny adresar /root ma prava rwx------ a do nho namountujes nejaky mountpoint, kt. uz ma prava rwxr-xr-x , tak uvids prava /root rwxr-xr-x , ovsem aby si do toho mohol vliezt a citat ,potrebujes mat prava na execute v celej ceste t.j. / , potom adresar /root pred mountovanim a /root po mountovani

pre komplikovanejsiu strukturu napriklad /usr/local/bin/root , kde /usr je jeden mountpoint a /usr/local druhy je to este zaujimavejsie

[Karel]

Zajímavý postřeh. Má to svou logiku. Dík.