În cele din urmă am aflat ce cauza funcționalitatea asta ciudată - se pare că NAS-ul rulează un kernel cu un patch "trustees" care îl face să ignore permisiunile POSIX și să aplice cu totul alte permisiuni: http://mockmoon-cybernetics.ch/computer/wdh1nc10000/trustees.html
Acum pot să dorm mai liniștit noaptea... 2013/10/1 Adrian Popa <[email protected]> > Solved: Am reușit să îl fac să meargă, deși nu înțeleg unde e implementată > limitarea. Soluția: am folosit interfața web de management să creez useri > și să dau permisiuni pe share-urile generate. După ce am dat permisiunile > respective am avut și acces. Ciudat e că din punct de vedere al drepturilor > la nivel de filesystem, lucrurile arată ca și până acum... Nu mi-e clar > deloc cum e implementată restricția - miroase a selinux, dar nu văd urme pe > nicăieri... > > ~ $ id > uid=503(adrianp) gid=1000(jewab) > > ~ $ ls -ld /shares > drwxr-xr-x 8 root jewab 4096 Sep 30 13:29 /shares > > ~ $ ls -ld /shares/Kits > drwxrwxrwx 3 root jewab 20 Sep 30 12:26 /shares/Kits > > ~ $ ls -ld /shares/Kits/android > drwxrwxrwx 3 adrianp root 22 Oct 1 10:02 > /shares/Kits/android > ~ $ > > > Mulțumesc tuturor pentru sugestii. Dacă aveți idee care e mecanismul de > restricționare mi-ar plăcea să aflu și eu și să mai învăț ceva nou. > (Înainte pe NAS aveam un firmware mai vechi care nu avea sistemul ăsta de > permisiuni, dar după ce i-am făcut upgrade, se pare că au apărut > "feature-uri" noi). > > > 2013/9/30 Adrian Popa <[email protected]> > >> Uite așa arată mount vs /proc/mounts: >> >> [root@aldebaran ~]# mount >> securityfs on /sys/kernel/security type securityfs (rw) >> >> /dev/md2 on /DataVolume type xfs (rw,usrquota) >> /dev/md4 on /ExtendVolume type xfs (rw,usrquota) >> >> >> [root@aldebaran ~]# cat /proc/mounts >> rootfs / rootfs rw 0 0 >> /dev/root / ext3 rw,noatime,data=ordered 0 0 >> proc /proc proc rw 0 0 >> sys /sys sysfs rw 0 0 >> /dev/pts /dev/pts devpts rw 0 0 >> securityfs /sys/kernel/security securityfs rw 0 0 >> /dev/md3 /var ext3 rw,noatime,data=ordered 0 0 >> /dev/md2 /DataVolume xfs rw,noatime,uqnoenforce 0 0 >> /dev/ram0 /mnt/ram tmpfs rw 0 0 >> /dev/md2 /shares/Public xfs rw,noatime,uqnoenforce 0 0 >> /dev/md2 /shares/Download xfs rw,noatime,uqnoenforce 0 0 >> /dev/md2 /shares/Kits xfs rw,noatime,uqnoenforce 0 0 >> /dev/md2 /shares/Movies xfs rw,noatime,uqnoenforce 0 0 >> /dev/md2 /shares/Music xfs rw,noatime,uqnoenforce 0 0 >> >> >> Share-urile respective sunt făcute din sistemul lui de management >> (teoretic sunt exportate ca share-uri samba/nfs). >> >> >> 2013/9/30 Nicu <[email protected]> >> >>> 2013/9/30 Nicu <[email protected]> >>> >>> > 2013/9/30 Adrian Popa <[email protected]> >>> > >>> >> Cred că dacă ar fi fost bind-mounted, ar fi apărut în output-ul lui >>> mount, >>> >> nu? În cazul meu nu apare. Directoarele au un hard link count > 1: >>> >> >>> > >>> > uita-te si-n /proc/mounts >>> > >>> >>> si-n plus, sistemul ala poate ca foloseste clone(CLONE_NEWNS) -- desi eu >>> n-am intilnit pina acum. >>> _______________________________________________ >>> RLUG mailing list >>> [email protected] >>> http://lists.lug.ro/mailman/listinfo/rlug >>> >> >> > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
