KNetworkManager, KPowerSave i problemy z uprawnieniami
Ostatnia aktualizacja Debiana Sid była dość desktrukcyjna dla mojego systemu… Padł GIMP (niezgodność wersji gimp i gimp-data), dodanie nowych X-ów spowodowało błędy ABI o których pisał Hadret i co chyba najgorsze – uruchamianie KPowerSave oraz KNetworkManager powodowało po kilku(nastu) sekundach sprzętowe zwisy komputera… Dodatkowo – KNetworkManager nie widział żadnych interfejsów sieciowych a KPowerSave nie potrafił regulować częstotliwości pracy procesora i podświetlenia matrycy. Uruchomienie tych aplikacji pod kontem roota dawało pozytywne efekty (wszystkie opcje działały), jednak tylko przez kilkanaście sekund – sprzętowy zwis. Słowem – koszmar na kilkadziesiąt minut zabawy…
Dla potomności i samoinformacji (swoisty reminder) zamieszczam rozwiązanie problemu z KPowerSave i KNetworkManager. Cała wina leży po stronie D-BUS a raczej jego najnowszej wersji, która wprowadza zaawansowane profile uprawnień. Zaglądając do:
$ cat /etc/dbus-1/system.d/knetworkmanager.conf
Widzimy „policies„, czyli nasze profile. I co? „Default„ jest na ustawione na „deny„ w każdym przypadku… Hmmm… Patrząc dalej zauważamy sygnowaną grupę, dla której flagi ustawione są na „allow„. No to:
# groupadd night netdev
Bądź też zmieniamy ustawienia „Default„ – wtedy każdy użytkownik będzie miał dostęp do zmiany ustawień sieci poprzez knetworkmanager. Analogicznie postępujemy dla kpowersave i innych programów, które korzystając z D-BUS poprawnie działają pod root‘em a na kontach użytkowników sprawiają problemy..
Voila! Wiem, nie wysiliłem się z wpisem, ale siedziałem troszkę nad tym aby zrozumieć mechanizm działania nowego systemu D-BUS. Boję się KDE4, które całe przejdzie na D-BUS...
Touchlib i OpenTouch czyli ekrany wielodotykowe
Pamiętacie film „Raport Mniejszości”? John Anderton korzystał w nim z ekranu dotykowego dużej rozdzielczości do „podglądania” przyszłości. Fikcja? Nie, ta technologia jest już w zasięgu ręki! No, może nie podglądanie przyszłości :-).
Ekran wielodotykowy to urządzenie, które pozwala komunikować się z użytkownikiem poprzez wygodny interfejs panelu dotykowego. Co go jednak wyróżnia to możliwość rozpoznawania wielu równoczesnych zdarzeń, np. używania panelu przez kilka osób jednocześnie.
Firma Microsoft zaprojektowała i stworzyła Microsoft Surface. Projektem zainteresowało się wojsko, kasyna w Vegas i największe hotele świata. Możecie sobie tylko wyobrazić jak wiele pieniędzy to może kosztować.
O samym Microsoft Surface możecie poczytać tutaj a prezentację macie poniżej:
Zapytacie pewnie – a jaki ma to związek z Wolnym Oprogramowaniem? Ma i to dość spory. Touchlib i OpenTouch to otwarte biblioteki do obsługi paneli wielodotykowych. Co ciekawe OpenTouch rozwijane jest przez naszego rodaka: Pawła Sołygę!.
No to super. Mamy całkowicie otwarte biblioteki do obsługi panelu wielodotykowego ale… ciągle nie mamy samego ekranu… Więc czemu sobie takowego nie zbudować?
NUI Group to grupa miłośników technologii naturalnych interfejsów komunikacyjnych. Na ich stronie oraz forum możemy znaleźć osoby, które zajmują się tworzeniem na własną rękę ekranów w technologii Frustrated Total Internal Reflection (FTIR). Sam mechanizm takiego panelu działa na zasadzie całkowitego węwnętrznego odbicia w dość grubej warstwie pleksi.
Złożenie ekranu wielodotykowego jest dość drogie i zajmuje troszkę czasu. Mały ekran 12×15cm możemy zbudować za około 600zł, duże panele (ponad metr szerokości) kosztować nas mogą do kilku tysięcy złotych. Po szczegółowe informacje na temat budowy zapraszam na forum NUI Group, a poniżej krótka prezentacja z możliwości własnego panelu wielodotykowego obsługiwanego przez otwarte bilbioteki touchlib:
Prezentację konkretnego zastosowania możecie zobaczyć na tej stronie (polecam).
Jak się to ma do systemu GNU/Linux? Touchlib i OpenTouch można bez problemu uruchomić i oprogramować pod dowolnym systemem Linuksowym. Dodatkowo – istnieje projekt MPX. MPX to modyfikacja Serwera X tak, aby mógł on korzystać z bilbioteki TouchLib. Wyobrażacie sobie na tym Compiza? :-)
I już na koniec: Touchlib jest wieloplatformowy (uruchamia się na praktycznie każdym sprzęcie, od Maców po PC), wydajny (szybkie działanie zapewnia średniej klasy komputer PC), skalowalny i wolny. Cóż więcej chcieć? Chyba zaczynam odkładać pieniążki na MyBox – mały panel wielodotykowy budowany przez NUI Group za cenę około 250zł. Niestety, nie wyświetla on obrazu, pozwala tylko pobawić się samych Touchlib…
Conky 1.4.7 dla Debiana (paczka deb)
Dwa tygodnie temu wydana została najnowsza wersja monitora systemowego Conky. Jak zwykle już – zbudowałem paczkę dla systemu Debian Sid. Paczka powinna zadziałać także w Debianie z gałęzi Testing. W tej wersji programiści dodali:
- moduł kolorowania składni pliku .conkyrc dla nano (w końcu działa!)
- zmienną $hwmon – wykorzystywaną do lm_sensors
- bezpośrednią implementację RSS (chociaż niektórzy nadal pewnie wolą swoje skrypty :-))
- monitorowanie stanu sieci bezprzewodowej
- kilka pomniejszych zmian w treści licencji i samym kodzie
Aby ściągnąć paczkę kliknij TUTAJ
Jeśli czegoś zabraknie w powyższej paczce proszę o powiadomienie, zbuduje się nową z „dodatkowymi funkcjonalnościami”.
ENJOY!
Wywołania systemowe w systemie GNU/Linux
Na początku krótkie wyjaśnienie tego czym jest wywołanie systemowe w ogólnym tego słowa znaczeniu. Wywołanie systemowe (System Call) to funkcja używana przez proces w celu zażądania od systemu operacyjnego (a ściślej - jądra) określonej usługi. Wywołania systemowe są generowane przez przerwania w samym programie (procesie).
Nowoczesne procesory przetwarzają instrukcje w kilkudziesięciu trybach dostępu (różniących się poziomem bezpieczeństwa oraz np. czasem trwania). W systemie GNU/Linux, definiujemy tylko dwa tryby - Tryb Użytkownika oraz Tryb Nadzorcy. Poziomy dostępu zostały stworzone po to, aby system mógł w prosty i jasny sposób decydować o przyznaniu dostępu do zasobów dla procesu. Jądro systemu operacyjnego GNU/Linux uruchamiane jest zawsze w uprzywilejowanym trybie - z oczywistej przyczyny - musi przyznawać dostęp do warstwy sprzętowej dla aplikacji (warstwy programowej), zarządzać przerwaniami, zmieniać tryb dostępu procesora czy też zarządzać pamięcią (tutaj przychodzi ku pomocy sheduler, którego opisałem całkiem niedawno).
Jednak system (kernel) sam w sobie nie potrafi kontrolować mechanizmu zmiany trybu dostępu. Aby zapewnić obsługę sytuacji, w której mnie uprzywilejowany kod transferuje swoje dane (lub jakiekolwiek wygenerowane przez niego) do wyżej uprzywilejowanego kodu potrzebujemy małego "włamu" i przełamania zabezpieczeń. Oczywiście - nie dosłownie. Nie możemy dopuścić do hipotetycznej sytuacji, w które mniej uprzywilejowany proces stara się wymusić na procesie o wyższym priorytecie np. błąd stosu. Standardowo system operacyjny dostarczany jest z biblioteką obsługującą zdarzenia i pośredniczącą między jądrem a procesem. W GNU/Linux tą biblioteką jest libc (Biblioteka C). To ona zarządza i nadzoruje wszystkie niskopoziomowe przepływy informacji pomiędzy procesami i kernelem, a także dzięki niej odbywa się "magiczna zamiana" trybu pracy procesora (z mniej uprzywilejowanego na bardziej lub na odwrót).
Posiadamy więc bibliotekę, którą użytkownik może wywołać w swoim programie i skorzystać z jej funkcji, aby przekazać "coś" "gdzieś" (mówiąc kolokwialnie:)). Przyjrzyjmy się zatem troszkę bliżej libc a w szczególności tematem wywołań systemowych. Jako przykład zatem - kawałek kodu odpowiedzialny za ustawienie UID w GNU/Linuksie.
_syscall1(int,setuid,uid_t,uid); _setuid: subl $4,%exp pushl %ebx movzwl 12(%esp),%eax movl %eax,4(%esp) movl $23,%eax movl 4(%esp),%ebx int $0x80 movl %eax,%edx testl %edx,%edx jge L2 negl %edx movl %edx,_errno movl $-1,%eax popl %ebx addl $4,%esp ret L2: movl %edx,%eax popl %ebx addl $4,%esp ret
Jak widać - operujemy assemblerem. Każda funkcja posiada co najmniej 2 argumenty: numer wywołania systemowego i rodzaj (definicję) działania tegoż wywołania. Każda funkcja wywołania systemowego biblioteki libc zwalnia przerwanie 0x80. Z tego adresu możemy pobrać (np. strace'm) wszystkie wywołania systemowe dowolnego programu. Gdy przerwanie zwolni się (najczęściej po określonym w jądrze "tiku"(czasie)) kod wyjścia jest pobierany z pamięci i możliwy do odczytania przez inną funkcję, bądź też przez wymieniony strace. Argumenty przekazywane są w rejestrach w następującej kolejności: eax, ebx, ecx, edx, edi, esi, ebp. Numer funkcji systemowej jest przekazywany w eax.
Całą pracę za wywołania przejmuje system przerwań. Po wywołaniu funkcji system_call() "praca" rozpoczyna się w 'adresie wejścia', który jest zdefiniowany w arch/i386/kernel/entry. Niestety, rutyny te zapisane są w języku niezrozumiałym dla przeciętnego człowieka. Stąd też krótki algorytm, jako ilustracja tego co dzieje się w czasie wywołania systemowego:
zwraca typ system_call(sys_call_number, sys_call_arguments)
{
Zapisz rejestry procesu;
Sprawdź, czy sys_call_number reprezentuje prawdziwą wartość wywołania;
jeśli nie pokaż błąd
w innym wypadku
{
Sprawdź flagę PF_TRACESYS wybranego procesu;
Wywołaj planistę (jeśli potrzebny);
Przekaż sygnały;
Swolnij rejestry procesu;
}
}
I krótkie wyjaśnienie//opis opisanego algorytmu. Dwie zmienne są przekazywane do rutyny: Sys_call_number odwołuje się do wcześniej zdefiniowanej liczby identyfikującej wywołanie systemowe. Sys_call_arguments przekazuje kolejne argumenty dla wywołania (jeśli potrzebne). Zapisanie rejestrów jest potrzebne, gdyż bez tego wywołanie planisty w późniejszym czasie mogłoby skutkować SIGSEGV. Następnie - sprawdzenie czy numer wywołania jest prawidłowy. Flaga PF_TRACESYS pozwala stwierdzić, czy dany proces nie ma procesu-rodzica. Tutaj wchodzi do gry funkcja syscall_trace (oto jej kod źródłowy arch/i386/kernel/ptrace.c). Jeśli wykryje rodzica przesyła mu SIGTRAP, wcześniej ustawiając procesowi potomnemu flagę TASK_STOPPED. Tutaj wkracza nasz dzielny planista i robi co do niego należy - zajmuje się pamięcią obu procesów (bądź jednego, jeśli proces nie miał rodzica). Jeśli wysłaniu sygnału SIGTRAP i pracy planisty proces dostał//wysłał jakikolwiek sygnał zostaje on przetworzony w tym momencie, po czym przywracane są rejestry.
I na koniec przykład użycia. Oto kawałek strace dla /bin/true:
brk(0) = 0x804a308 brk(0x804b308) = 0x804b308 brk(0x804c000) = 0x804c000 _exit(0)
Przepiękny pogląd na funkcję brk(), która poprzez przerwanie (wywołanie systemowe) odwołała się do pamięci (adres 0x804a308). Program bez praw dostępu do pamięci (przynajmniej bezpośrednio - nie działający w trybie uprzywilejowanym) poprzez System Call odwołał się do jądra, aby ten dał mu mały fragment wolnej pamięci.
Celowo nie opisuję sposobu tworzenia własnych wywołań systemowych. Zainteresowani zajrzą zapewne do Google, a niezainteresowani w końcu skończą czytać ten nudny wpis :-).
I tą oto jogg-notką powracam do żywych :-) Witajcie już oficjalnie! Następny odcinek mam już praktycznie napisany - a w nim... DCOP - jedna z rzeczy za które kocham KDE! :-) Stay Tuned!
Conky 1.4.5 dla Debiana (paczka deb)
Jak niektórzy z Was wiedzą, jestem ogromnym fanem monitora systemowego "Conky", tworzę do niego skrypty, ulepszam go itp. itd. Niestety, w repozytoriach Debiana (jak i w repo Ubuntu starszych niż 6.10) znajduje się bardzo stara wersja tego programu. Dlatego staram się budować najnowsze paczki Conky dla obu tych systemów. Dziś kolej na Debiana :-)
Conky został skompilowany na Debian Lenny w następujący sposób:
Conky 1.4.5 compiled Sat Jun 16 13:23:03 CEST 2007 for Linux 2.6.21 (i686) Compiled in features: * x11: x11 support: yes xdamage support: yes xdbe support: yes xft support: yes * music detection: audacious: no bmpx: no mpd: yes xmms2: no * general: hddtemp: yes portmon: yes
A paczuszka znajduje się tutaj:
link 1 link 2
Aby zainstalować ową paczkę radzę najpierw pobrać Conky z oficjalnych repozytoriów, a dopiero potem, wykorzystując dpkg zainstalować moją paczkę. Pakiecik dla Ubuntu pojawi się, gdy tylko będę mieć dostęp do ww. systemu
Enjoy!
