Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
[quote=KerneLpaniC]Zamiast podać hasło do roota w synapticu podałem je na odpalonym ircu ;-)[/quote]
Bywa :)
Ja kiedyś w bankomacie, zamist pin-u 3x wklepałem nr rej samochodu. Kartę mi zeżarło :(
Offline
Z tego roku
Wkleiłem swoje hasło do [b]dug[/b]'a na CB. Nigdy nie przechowuje haseł w całości i sklejam je sobie zawsze w jakimś tam notatniku z reguły AbiWord. Po zalogowaniu zapomniałem zamknąć procesor i zamiast linku, w sobie tylko znany sposób wkleiłem swoje hasło. Żeby było śmieszniej w panice zamiast [b]Backspace[/b] wcisnąłem [b]Enter[/b] i poszło.
[b]Hashowałem[/b] # sobie jedno repozytorium, a następnie wiązałem się za zmianę tapety w LightDM. Podałem swoją ścieżkę żeby zmienić domyślną tapetę. Oczywiście nie zadziałało ponieważ przed background= nie usunąłem hash'a # . Zorientowanie się w tym zajęło mi kilkanaście godzin.
Ciepło mi się zrobiło jak bawiłem się [b]Deepin[/b]'em. Późno było i szukałem czegoś na pendrive. Przewijałem sobie rolką zawartość folderu i nagle wszystkie nazwy plików po rosyjsku. Minę miałem nietęgą, zimny pot ... . Pierwsze co zrobiłem to odłączenie router'a od sieci. Potem chwila oddechu i biorę się za sprawdzanie ... Czasami przy przewijaniu na sterach Nvidii obraz faluje (i trzeba grzebać w configu) zwłaszcza jak korzysta się z przeglądarek. Dodatkowo menadżer plików się przyciął przy przewijaniu, a ja zapomniałem, że w otwartym folderze miałem rosyjskie normy [b]ГОСТ[/b].
Ostatnio edytowany przez ciastek1981 (2017-12-28 14:23:49)
Offline
W tym roku to sobie nic nie zepsułem. No może to podciągnąć.
Stawiam system od nowa. Sformatowałem sobie dysk... nosz kurwa, tam były dane ludzi w katalogu z chmury.
Chwila paniki, nie no przecież - ścieżka w cronie na dysk na drugiej maszynie. Ufff.
Offline
Zapomniałem jeszcze o jednej wpadce. Przy użyciu [b]dd[/b] wrzuciłem na partycję z obrazem Windowsa obraz Debiana. Pendrak i partycja pokazywały po 7,2 GB xD
Offline
Mi się zdarzyło raz przez [b]dd[/b] wrzucić obraz iso na dysk systemowy zamiast na pendrive.
Na szczęście połapałem się co odwaliłem, bez rebootu zmiany się nie zastosowały więc backup uratował dupsko.
Offline
Dla tych co szyfrują dane na dyskach — gdy zobaczycie taki poniższy warning, nie wpisujcie [b]YES[/b] xD:
WARNING!
========
Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
data on that device.
Are you sure? (Type uppercase yes): [b]YES[/b][/quote]
Akurat sobie porządkowałem rzeczy na dysku z okazji dokupienia nowego talerzowca 1T, no i zapragnąłem tam sobie machnąć szyfrowany LVM z odłączonym nagłówkiem na karcie SD. No i wszystko ładnie szło do momentu aż się okazało, że mój laptop chyba nie potrafi startować z czytnika kart i nie mogę tam dać partycji /boot/ wraz z nagłówkami szyfrowanych dysków. No i w sumie został mi taki niezgrabny setup, to myślę "wgram ten nagłówek na partycję i będzie tak jakbym go nie odłączał". xD
Problem w tym, że przy tworzeniu kontenera z odłączonym nagłówkiem tworzony jest offset=0 na dane, a nie 4MiB tak jak to jest w standardowym przypadku. No i wgrałem sobie na początek partycji te 4 MiB, co uwaliło efektywnie szyfrowany kontener, LVM i wszystko w nim. xD oczywiście backupu nie robiłem, bo nauczyłem się już wcześniej, że backupy i tak nie pomagają w kryzysowych sytuacjach i tylko się czas traci próbując przywrócić dane za ich pomocą. xD Na szczęście ja w takich sytuacjach nie tracę głowy, no i postanowiłem jakoś te 1T danych odzyskać. Prawie wszystko udało się odtworzyć bez większego problemu: kontener, strukturę lvm i dwa z trzech dysków logicznych. Nawalił oczywiście pierwszy dysk logiczny, bo rozwaliłem mu superblock no i oczywiście dziennik, który rezyduje na pierwszych 128 MiB. Całe szczęście, że te nagłówki mają tylko 4 MiB. xD Przydał się fsck z alternatywnym superblokiem i po dłuższej chwili klikania "FIX? YES", można było wreszcie zamontować ten uszkodzony system plików i oczywiście dane pozostały nietknięte. Także to taka lekcja na przyszłość — backupy ssą. xD A teraz to już tylko pozostało rozszerzyć partycję o te 4 MiB i wgrać na początek nagłówek ale to już tylko czysta formalność.
Offline
[quote=morfik]Dla tych co szyfrują dane na dyskach — gdy zobaczycie taki poniższy warning, nie wpisujcie [b]YES[/b] xD:
WARNING!
========
Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
data on that device.
Are you sure? (Type uppercase yes): [b]YES[/b][/quote]
Akurat sobie porządkowałem rzeczy na dysku z okazji dokupienia nowego talerzowca 1T, no i zapragnąłem tam sobie machnąć szyfrowany LVM z odłączonym nagłówkiem na karcie SD. No i wszystko ładnie szło do momentu aż się okazało, że mój laptop chyba nie potrafi startować z czytnika kart i nie mogę tam dać partycji /boot/ wraz z nagłówkami szyfrowanych dysków. No i w sumie został mi taki niezgrabny setup, to myślę "wgram ten nagłówek na partycję i będzie tak jakbym go nie odłączał". xD
Problem w tym, że przy tworzeniu kontenera z odłączonym nagłówkiem tworzony jest offset=0 na dane, a nie 4MiB tak jak to jest w standardowym przypadku. No i wgrałem sobie na początek partycji te 4 MiB, co uwaliło efektywnie szyfrowany kontener, LVM i wszystko w nim. xD oczywiście backupu nie robiłem, bo nauczyłem się już wcześniej, że backupy i tak nie pomagają w kryzysowych sytuacjach i tylko się czas traci próbując przywrócić dane za ich pomocą. xD Na szczęście ja w takich sytuacjach nie tracę głowy, no i postanowiłem jakoś te 1T danych odzyskać. Prawie wszystko udało się odtworzyć bez większego problemu: kontener, strukturę lvm i dwa z trzech dysków logicznych. Nawalił oczywiście pierwszy dysk logiczny, bo rozwaliłem mu superblock no i oczywiście dziennik, który rezyduje na pierwszych 128 MiB. Całe szczęście, że te nagłówki mają tylko 4 MiB. xD Przydał się fsck z alternatywnym superblokiem i po dłuższej chwili klikania "FIX? YES", można było wreszcie zamontować ten uszkodzony system plików i oczywiście dane pozostały nietknięte. Także to taka lekcja na przyszłość — backupy ssą. xD A teraz to już tylko pozostało rozszerzyć partycję o te 4 MiB i wgrać na początek nagłówek ale to już tylko czysta formalność.[/quote]
tez kiedys niechcacy nadgralem poczatek :P
Offline
nie zrobienie kopii klucza keepassx i zerówka dyzia na którym była jedyna kopia (pijany), potem to już odzysk haseł z pamięci własnej, 90% poszła w /dev/null, 5% była przypięta do nr telefonu/głównego maila czyli do odzyskania, 5% zapamiętana
wnioski > nie ufaj alkoholowi i danym cyfrowym
lekcja > nie rób po pijaku rzeczy których potem będziesz żałował :)
Ostatnio edytowany przez hi (2018-02-16 19:39:32)
Offline
eh błędy trzeba przeżyć samemu to jak jebnięcie młotkiem w potylicę, po za tym wszystko co w sieci ma dla mnie znikomą wartość a to co mnie otacza materialnie jeszcze mniejszą to skumulowana wiedza przykładowo na Twojej stronie ma dla mnie o wiele większa wartość niż jakiś gadżet ...
https://www.youtube.com/watch?v=v3yA0xXXVCw
wróć stronę #! :)
Ostatnio edytowany przez hi (2018-02-17 00:00:33)
Offline
Czasami brakuje mi ubuntu i jego problemów kiedy patrzę na to, co mi się przytrafia na debianie. xD
Cała sytuacja miała miejsce niedawno, gdy to chciałem powrócić do oldskulowych mechanizmów startu systemu, po tym jak się okazało, że crypttab/systemd/plymouth nie są ze sobą kompatybilne i trzeba jakieś czary dziwne odprawiać, by zamontować zaszyfrowane dyski za pomocą jednego hasła. Okazało się też, że nikt z tym nie ma zamiaru nic zrobić i najwyraźniej ten stan rzeczy się utrzyma przez jeszcze jakiś czas. Niby rozwiązanie systemd+plymouth mi w miarę odpowiadało ale miało ono jakieś problemy z fontami na TTY i bugowało pojawiające się komunikaty podczas startu systemu, gdy się wcisnęło ESC. Dlatego postanowiłem wyłączyć obsługę LUKS w systemd i przejść na debianowego /etc/crypttab w połączeniu ze skryptem keyctl, który wykorzystuje hasło zapisane w kernelu do odpalenia wszystkich kontenerów, które się w crypttab znajdują.
Niby prosta rzecz, wywalić plymouth i odpowiednio uzupełnić crypttab ale jak zwykle coś poszło nie tak. Po zrebootowaniu systemu, okazało się, że ten nie chce wystartować. xD Problemem były zaginione pliki w initramfs, które powinny zostać do niego dołączone ale ... najwyraźniej nie zostały. xD Dlaczego nie zostały? Bo ktoś ustawił w skryptach cryptsetup by check, który miał sprawdzać zainstalowanie plików był "-x". No fakt, trzeba było zainstalować w initramfs skrypt i pewnie dlatego weryfikacja poszła po atrybucie wykonywalności, tylko najwyraźniej ktoś nie przewidział, że można korzystać z systemu mając /tmp/ i /var/tmp/ zamontowane z noexec i w takim przypadku najwyraźniej ten check zwraca false i dlatego tych plików zabrakło.
To jednak nic, bo mając taki niebootwalny system, trzeba go jakoś odratować i na nowo initramfs wygenerować (tym razem z tymi partycjami zamontowanymi z exec) -- czyli standard live+chroot. Ja mam w telefonie obraz live debiana właśnie na tego typu okoliczność. W takim przypadku jak ten, taki obraz udostępnia się po USB z telefonu za sprawą USB-Gadget i można wystartować system live. No i faktycznie system live wystartował. Wiedziałem, że obraz live ze stabilnym debianem nie odszyfruje mojego LUKSv2, dlatego chciałem zainstalować potrzebne pakiety z SID'a ale okazało się, że najwyraźniej ktoś nie dołączył do tego obrazu live sterów/firmware do karty WiFi mojego laptopa, a tak się składa, że mój telefon robi również obecnie za router/AP WiFi i udostępnia połączenie LTE właśnie po WiFi i nie mam innej opcji uzyskania połączenia z netem na laptopie jak przez WiFi. No ale od czego jest USB-tethering, no i czym prędzej przełączyłem telefon w ten tryb i... mój system live szlag trafił. xD No może nie powiesił się ale nie dało rady nic już uruchomić, bo najwyraźniej USB-tethering i USB-Gadget nie są w stanie istnieć razem i jeden wyłącza drugi, co skutecznie uwala pracę na systemie live. Do tego dochodzi jeszcze fakt, że ja mam całą partycję /boot/ w obrazie IMG w telefonie i ten obraz jest również udostępniany przez USB-Gadget. Także jak w takiej sytuacji odpalić i zaktualizować system live, z poziomu którego można zaktualizować initramfs? Chyba się nie da. xD
Na szczęście w szafce jeszcze leżał jakiś stary pen z epoki dinozaurów, na którym był debian, który pamiętał jeszcze czasy wielkiego wybuchu i to na nim odpaliłem system live, a potem fona przełączyłem w tryb USB-tethering na aktualizację potrzebnych pakietów, a potem by podmontować obraz /boot/ i zaktualizować initramfs. Także mogliby jakoś te mechanizmy USB-Gadget i USB-tethering rozbudować, bo obecnie są one jakoś niezbyt używalne. xD
Offline
[quote=morfik]Czasami brakuje mi ubuntu i jego problemów kiedy patrzę na to, co mi się przytrafia na debianie. xD[/quote]
Głupoty gadasz, korzystałem z sida przez kilka lat po czym przesiadłem się na Xubuntu LTS - bo połowę systemu po instalacji jest gotowa do pracy i na tyle "stabilna", że aż równoznaczna z sidem, za to mniej roboty z konfiguracją. Tyle tylko muszę zmienić, co wiem że mi się wywali. Na lapku Xubuntu LTS chodzi od momentu wydania, na stacjonarce od 2 miesięcy i nie mam z nimi problemów.
Offline
E, ale to było napisane w tonie obalenia hipotez, że ubuntu jest jakieś gorsze od debiana. xD A fakt jest taki, że jeśli już ktoś coś bardziej zaawansowanego będzie robił na debianie to co chwila uderzy w jakieś bugi, bo niewiele ludzi zabrnęło w ten obszar otwartego oceanu by móc w ogóle doświadczyć pewnych aspektów z tym związanych. No bo kto montuje domyślnie sobie /tmp i /var/tmp z noexec? Swoją drogą to ciekawe, bo ten skrypt i tak miał atrybut -x i noexec go nie cofa. Przykład:
# touch /tmp/exe
# chmod +x /tmp/exe
# ls -al /tmp/exe
-rwxr-xr-x 1 root root 0 2018-12-01 22:44:32 /tmp/exe*
# mount | grep \/tmp
/dev/mapper/wd_black_label-tmp on /tmp type ext4 (rw,nosuid,nodev,[b]noexec[/b],relatime,block_validity,delalloc,nojournal_checksum,barrier,user_xattr,acl,errors=remount-ro)[/quote]
Więc jakim cudem ten check -x zwraca false skoro jak byk ten plik ma x'a. xD
Offline
Więc jakim cudem ten check -x zwraca false skoro jak byk ten plik ma x'a. xD[/quote]
Po prostu żeby plik mógł być uruchomiony musi:
*) mieć uprawnienia execute
*) być na partycji z uprawnieniami execute
W sumie jakby polecenie chmod +x /tmp/exe nie dawało efektu bo partycja jest zamontowana z noexec to też by było źle - bo żeby plik wykonać musiałbyś przemonotwać partycje i nadać uprawnienie do pliku, a tak wystarczy tylko jedno ;)
linux register user: 484281
"[i]It's great to be here. It's great to be anywhere[/i]"
[b]Keith Richards[/b]
Offline
Nie no, ja rozumiem, że plik może być wykonany, gdy te dwa warunki są spełnione ale tutaj pliku się nie wykonuje, ino sprawdza czy można go wykonać, a to chyba nie to samo, czy się mylę? xD
Generalnie to chodzi o coś takiego:
# Check whether cryptroot hook has installed decrypt_keyctl script if [ ! -x "$DESTDIR/lib/cryptsetup/scripts/decrypt_keyctl" ]; then exit 0 fi
Czyli skrypt kopiujący pliki do obrazu initramfs kopiuje do tego tymczasowego $DESTDIR/ plik decrypt_keyct, który jest skryptem. No i zgodnie z opisem sprawdzane jest czy został on poprawnie zainstalowany.
Ostatnio edytowany przez morfik (2018-12-02 14:18:03)
Offline
W dyskusji o noexec na partycji trzeba pamiętać, ze noexec zawsze ograniczy działanie plików binarnych elf, ale już skryptów Shell, PHP, Pythona czy Perla niekoniecznie.
Dowód rzeczowy:
echo -e '\n#!/bin/bash\n\necho noexec nie działa\!\n' >/tmp/test.sh chmod 755 /tmp/test.sh /tmp/test.sh bash: /tmp/test.sh: Brak dostępu
noexec zadziałał prawidłowo, ale:
source /tmp/test.sh noexec nie działa!
tutaj noexec jest bezradny.
Pozdro
Ostatnio edytowany przez Jacekalex (2018-12-02 17:29:52)
Offline
[quote=Jacekalex]W dyskusji o noexec na partycji trzeba pamiętać, ze noexec zawsze ograniczy działanie plików binarnych elf, ale już skryptów Shell, PHP, Pythona czy Perla niekoniecznie.
Dowód rzeczowy:
echo -e '\n#!/bin/bash\n\necho noexec nie działa\!\n' >/tmp/test.sh chmod 755 /tmp/test.sh /tmp/test.sh bash: /tmp/test.sh: Brak dostępu
noexec zadziałał prawidłowo, ale:
source /tmp/test.sh noexec nie działa!
tutaj noexec jest bezradny.
Pozdro[/quote]
Niczego nie dowiodłeś. W swoim przykładzie tak na prawdę nie wykonujesz żadnego pliku, tylko wczytujesz kod z pliku i wykonujesz echo w bieżącej powłoce.
Offline
Tutaj niby jest przykład jak odpalić coś z noexec na tmp:
https://debian-administration.org/article/57/Making_/tmp_non-executable
Tylko ten art ma 15 lat i u mnie jednak przykład w nim zawarty zwraca błąd:
# /lib/ld-linux.so.2 /tmp/ls /tmp/ls: error while loading shared libraries: /tmp/ls: wrong ELF class: ELFCLASS64 # /lib/ld-linux.so.2 /bin/ls /bin/ls: error while loading shared libraries: /bin/ls: wrong ELF class: ELFCLASS64
I jak można wyczytać na internetach:
Modern kernels fix the /lib/ld-linux.so hole, so that it won't be able to map executable pages from a noexec filesystem.
-- https://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec[/quote]
Ale co ciekawe:Kod:
# /tmp/exe zsh: permission denied: /tmp/exe # sh /tmp/exe dupaxD
Ostatnio edytowany przez morfik (2018-12-03 13:08:51)
Offline
Taka mała uwaga dla tych, którzy mają zaszyfrowane Androidy i robią binarny backup partycji /data/ — czasami lepiej jest zajrzeć do pliku recovery.fstab , bo później podczas przywracania backupu można skoczyć z okna, zwłaszcza jak widnieje tam coś w stylu:
/data ext4 /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/userdata flags=display="data";backup=1;wipeingui;wipeduringfactoryreset;[b]forceencrypt=[/b]/dev/block/platform/mtk-msdc.0/11230000.msdc0/[b]by-name/metadata[/b][/quote]
Następnym razem jednak zrobię backup również i tej partycji /metadata/. xDOstatnio edytowany przez morfik (2019-01-28 01:56:22)
Offline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00054 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.97.9.170' WHERE u.id=1 |
0.00114 | UPDATE punbb_online SET logged=1733665366 WHERE ident='18.97.9.170' |
0.00022 | SELECT * FROM punbb_online WHERE logged<1733665066 |
0.00095 | DELETE FROM punbb_online WHERE ident='185.191.171.8' |
0.00064 | SELECT topic_id FROM punbb_posts WHERE id=322132 |
0.00009 | SELECT id FROM punbb_posts WHERE topic_id=225 ORDER BY posted |
0.00055 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=225 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.05611 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=225 ORDER BY p.id LIMIT 350,25 |
0.00103 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=225 |
Total query time: 0.06146 s |