dysk zewnętrzny z EXT4

Po moim pierwszym notebooku pozostał mi sprawny twardy dysk. Nabyłem swego czasu przenośną kieszeń Natec, przez długi czas dysk pracował z pozostawionym systemem plików NTFS. Jednak problemy przy przesyłaniu dużych plików z Linuksa, sprawiły że sformatowałem go nie opacznie na EXT4. Całą operacje przeprowadziłem już jakiś czas temu pod SUSE. I w Kameleonie wszystko jest cacy, jednak po wpięciu go do Fedory i próbie dostania się do jakigokolwiek katalogu, otrzymuję komunikat o braku prawach dostępu. Co prawda można owy dostęp wymusić, jednak szczerze mówiąc jest to frustrujące. Wydaje mi się że z VFAT32 nie było by takich problemów, więc może nie wszytko co z Redmond jest zaraz takie złe… Tfu co ja pisze!

Każdemu sformatowanemu dyskowi trzeba od razu nadać pełne uprawnienia. Wtedy każdy katalog czy plik umieszczony na nim uzyskuje takie uprawnienia, i nie ma problemów. Jak się o tym zapomni jest jak napisałeś.

Masz na myśli:


sudo chmod -R 777 *
\CODE]
Święta racja ! Jak bym grał w automaty, to bym miał zakodowane że siódemki przynoszą szczęście. A tak to problemy.
Ale w sumie to zastanawiające gdyż sam łańcuch w dostępie jest z goła bez znaczenia. Jeśli już ma coś znaczenie to UID a ten na obu systemach wynosi 1000. Gdyż zarówno w SUSE jak i  w Fedorze jest tylko jeden zwykly użytkownik. Jest jeszcze GID dla grup, ale i on w obu przypadkach wynosi 1000. A więc czego ten durny Nautilus się czepia. Ale zaraz, muszę to jeszcze zbadać w konsoli...

Dobra mam to !
W SUSE grupa 'users' ma GID ustawiony na 100
W Fedorze jestem domyślnie w grupie 'przem' o GID 1000
I jest również grupa 'users' o GID 100, ale nie jestem do niej przypisany
Więc wykonuje:

sudo usermod -a -G users przem


W następstwie czego Nuatilus już nie zgłasza żadnych uwag.
W Pingwinie nie ma czasu na nudę !

Swoją drogą nie jest dobrze przydzielać pełnych uprawnień, z uwagi że diabeł tkwi w szczególe.

To na koniec wytłumacz, co tu się stało:

> /tmp$ mkdir przem
> /tmp$ cd przem
> /tmp/przem$ whoami
przem
> /tmp/przem$ pwd
/tmp/przem
> /tmp/przem$ touch test1
> /tmp/przem$ ls -l
razem 0
-rw-r--r-- 1 przem przem 0 01-27 22:15 test1
> sudo -i
# userdel przem
# ls -l /tmp/przem/
razem 0
-rw-r--r-- 1 1001 1001 0 01-27 22:15 test1

Szefuniu proszę, czy ja wyglądam na admina ? Ja to zwykły lamer jestem !
Pozdrawiam

Ale zaraz, pamiętam że kiedyś dawno temu miałem zwyczaj rosmołowywać tarbale właśnie w ‘/tmp’. Jak się zdziwiłem jak po uprzednim upgradzie systemu, i wykonaniu rebootu z nie usuniętą ręcznie zawartością katalogu tymczasowego. nie mogłem odpalić X serwera ! Trochę czasu mi to zajęło, ale doszedłem do przyczyny. W sumie to było dziwne, naprawdę.

Zwróć uwagę, co się stało z uprawnieniami do pliku wyświetlanymi przez ls po usunięciu użytkownika i grupy, do których ten plik należał:

# ls -l /tmp/przem/ razem 0
-rw-r--r-- 1 1001 1001 0 01-27 22:15 test1

Ciekawe, zupełnie jak by wskazywał na innego usera. Choć szczerze mówiąc nie jestem świadom w jaki sposób jest przyznawany UID kolejnym użytkownikom. Jest jeszcze tyle do poznania i to nie tylko jeśli chodzi o nasz ulubiony system. Pytanie czy starczy na to wszystko czasu. A czas bezcenny.

Nie, zaraz u Ciebie użytkownik ‘przem’ jest jako drugi user - czyli jego UID to 1001. Więc chodzi o to że nie ‘istniejąca’ grupa przejęła identyfikator po użytkowniku. Tak to będzie leciało. Pytanie brzmi czy takie działanie nie wpływ na bezpieczeństwo - tak teorytzuje.

Kurcze, chyba popadłem w paranoje i odpłynąłem. Zadzwońcie po pogotowie, nie mnie zabiorą. Na miejscu zwiążą pasami, dadzą serie zastrzyków w brzuch przeciw wściekliźnie i zaczną karmić sondą !
Już dobrze, biorę się w garść. Po prostu jest tak jak napisałem wcześniej, że bardziej liczy się UID i GID niż nazwa użytkownika czy nazwa grupy. Po usunięciu użytkownika z systemu, w miejsce łańcuchów tekstowych wyświetlane są odpowiednio identyfikatory użytkownika i grupy. Ot wszystko.

Każdy plik jest przypisany do grupy i użytkownika. Czasami dystrybucje tworzą razem z użytkownikiem dedykowaną grupę o nazwie użytkownika. Bywa, że ich ID jest identyczne.

To co miałeś zobaczyć, to ID użytkownika i grupy, których system już nie mapuje do nazwy grupy i nazwy użytkownika. Dokładnie coś takiego się stało z Twoim dyskiem, jak przepiąłeś dysk z Fedory do openSUSE - id nie zostały rozwiązane, bo takich grup i użytkowników nie było. Osobiście lubię myśleć, że grupa i użytkownik, to de facto aliasy do wartości ID. I tyle. :slight_smile:

Można sprawdzić UID i GID użytkownika z wiersza poleceń (wcale nie trzeba eksplorować katalogu /etc), oraz przypomnieć sobie do jakich grup należy użytkownik. W mojej Fedorze komenda ‘id’ daje taki rezultat:

[przem@hel ~]$ id 
uid=1000(przem) gid=1000(przem) grupy=1000(przem),10(wheel),100(users),135(mock)

Widać jak na dłoni że dopisałem się do grupy ‘users’. Grupa ‘wheel’ umożliwia uzyskanie praw administratora, z kolei nie mam pojęcia co daje grupa ‘mock’.

Ach skleroza, nie rozumiem tylko dlaczego mnie dopada, skoro wcale nie jestem taki stary!
Przynależność do grupy ‘mock’ daje uprawnienie do budowania pakietów RPM, poleceniem ‘fedpkg’. Ale ze mnie łosiu, czasami mam wrażenie że ten cały Linux mnie nadto przytłacza. A może też dlatego że dawno nie budowałem pakietu lokalnie, tylko buduje w chmurze na OBS.