Utworzono zgłoszenie.

Produkt: immudex (Stabilna wersja dystrybucji GNU/Linux oparta na Debianie Stable.)
Komponent: System (Problemy lub ulepszenia ogólnego dobrostanu systemu.)
Rodzaj zgłoszenia: ulepszenie
Temat: Użytkownicy
Opis zgłoszenia: Trzeba zrobić porządek z użytkownikami, tj.:
- Nadać superużytkownikowi losowe hasło, nieznane nawet budującemu obraz. Dodatkowo, jeśli się da
zablokować możliwość logowania się na niego.
- Zapytać się budującego o nazwę użytkownika dla niego oraz hasło. Uwaga, za pomocą instrukcji
instrukcji 'adduser' wraz z przełącznikiem '--comment' ustawiony na pusty ciąg (''), żeby nie
pytał o pola GECOS. Dodać użytkownika do grup libvirt.
Skonfigurować 'sudo' aby pytał o hasło, lub dodać do grupy sudo.

Status zgłoszenia został zmieniony z Przyjęty na W trakcie

Konto superużytkownika jest zablokowne, jego hasło jest hash-em md5
obliczonym z 1MB danych z '/dev/random'. Użytkownik jest dodawany z pomocą polecenia
'useradd -m -s /bin/bash'. Nazwa użytkownika jest pobierana podczas budowania. Kopiowane są
'dotfiles' z '/etc/skel', ponieważ useradd tego nie robi. Tworzony użytkownik przypisywany jest
do grup: sudo, libvirt, libvirt-qemu.
Przegrupowano również narzędzia, na te które niewymagają uprawnień administrator oraz na te, które
tego potrzebują. Wyjątkiem jest narzędzie 'immudex-padlock', które przez problemy z uruchomieniem
terminala xfce przez sudo, pozostało bez zmian.
Zmiany zostały wdrożone, temat do zamknięcia.

Problematyczne również okazało się dostosowanie do polecenia
'immudex-crypt'. Niezbędne było określnie UID oraz nazwy użytkownika, która uruchomiła to
narzędzie wraz z sudo. Ze względu na to, że proces uruchomiony przez sudo będzie mieć ustawiony
UID na 0 (root), to skupiono się na poleceniu sudo. Jak można było się domyśleć proces powłoki
wykonującej skrypt jest procesem podrzędnym procesu sudo. Więc naszym celem jest ustalenie UID-u
procesu 'sudo'. Aby uzyskać UID, konkretnego procesu można odwołać się do pliku 'status'
procesów (PID) w interfejsie '/proc' (tj. '/proc/PID/status'). Tylko skąd wziąc PID tego procesu
sudo, które spawnuje wykonującą skrypt powłokę? Otóż na początku wykonano prostą arytmetykę.
Odjęto od PID-u procesu powłoki wartość 1 i tym PID-em odwołano się pod interfejsu '/proc'.
Problematyczne jednak okazał się moment, gdy użytkownik podał przy pierwszym wywołaniu błędne
hasło. Sudo najwidoczniej działa na takiej zasadzie, że jeśli podamy złe hasło, to proces się
rozwidla, następnie proces podrzędny tego pierwotnego pyta nas ponownie o hasło a tam ten proces
zostaje zakończony i wówczas my nie możemy uzyskać PID-u procesu. Rozwiązaniem okazało się
użycie polecenia 'pidof' wraz z przełącznikiem '-s'. Powoduje ono zwrócenie pojedynczego ('-s')
PID-u podanego procesu. Oczywiście na pierwszy rzut oka, można stwierdzić, że nie mamy pewności
czy to ten/te procesy (może ich być wiele, ze względu na charakterystykę narzędzia sudo)
odpowiadają za ten konkretny proces powłoki. Jednak w przypadku immudex nie ma to znaczenia.
Ten system będzie mieć tylko jednego realnego użytkownika przed sobą, więc nawet więcej wystąpień
sudo w systemie nic nie zmieni ponieważ UID procesu będzie taki sam.

Status zgłoszenia został zmieniony z W trakcie na Zakończony