🚀 go-pugleaf

Dnia 2010-03-08 22:23, Użytkownik Maciek sq7obj napisał:

> automatycznie zamazywałoby pliki które usuwam? Średnio podoba mi się
> idea zostawiania plików w całości na dysku, a wymazywanie całej wolnej
> przestrzeni trwa zbyt długo, i jest niepotrzebne...

Są przeróżne erasery, które wymazują tylko kasowane pliki. Część wolna -
np. http://eraser.heidi.ie/ ; przy czym pliki musisz kasować za ich
pomocą. Nie spotkałem się z narzędziem, które po instalacji w systemie
podmieniałoby standardową procedurę kasowania na wipowanie, niezależnie
od systemu operacyjnego (w unixach musiałby być to raczej moduł do jądra
przejmujący wywołania funkcji systemowych, w windows być może też).

L.

> a wymazywanie całej wolnej
> przestrzeni trwa zbyt długo, i jest niepotrzebne...

To ja się też zapytam. Jak skasować dane na wolnej przestrzeni w systemie 
Linux.

Lucjan J.A. Tumim wrote:
>> a wymazywanie całej wolnej
>> przestrzeni trwa zbyt długo, i jest niepotrzebne...
> 
> To ja się też zapytam. Jak skasować dane na wolnej przestrzeni w systemie 
> Linux.
> 

cat /dev/urandom > /home/plik

Do komunikatu o zapchaniu dysku :)

wer

Użytkownik Maciek sq7obj napisał:

> Hej.
> Czy jest może jakieś narzędzie działające pod Windowsem, które
> automatycznie zamazywałoby pliki które usuwam? Średnio podoba mi się
> idea zostawiania plików w całości na dysku, a wymazywanie całej wolnej
> przestrzeni trwa zbyt długo, i jest niepotrzebne...
> 
> Pozdrawiam,
> Maciek sq7obj
> 
Automatycznie to raczej nie ale zainteresuj się programem CCleaner. Po 
zakończonej pracy uruchamiasz i czyścisz. Nawet ma opcję wyboru ilości 
nadpisań przy usuwaniu i usuwa dane z wolnej przestrzeni dyskowej.
Maciek

On 9 Mar, 20:06, Maciek <macie...@polobox.com> wrote:
> Automatycznie to raczej nie ale zainteresuj się programem CCleaner. Po
> zakończonej pracy uruchamiasz i czyścisz. Nawet ma opcję wyboru ilości
> nadpisań przy usuwaniu i usuwa dane z wolnej przestrzeni dyskowej.
> Maciek

Do czegoś takiego mam Erasera, do którego link Luke podał pare postów
wyżej. Ale jednak jest to irytujące, bo żeby przelecieć kilkadziesiąt
GB wolnej przestrzeni potrzeba strasznie dużo czasu. Ręczne bezpieczne
usuwanie Eraserem czy czymkolwiek innym średnio mi odpowiada -
bezpiecznie usunięte zostaną tylko te pliki, które sam usuwałem -
jeżeli jakiś program użyje standardowych funkcji do skasowania np.
plików tymczasowych po sobie, to dane zostaną na dysku...

Luke <luke@luke.net> napisał(a):
> Dnia 2010-03-08 22:23, Użytkownik Maciek sq7obj napisał:
>
>> automatycznie zamazywałoby pliki które usuwam? Średnio podoba mi się
>> idea zostawiania plików w całości na dysku, a wymazywanie całej wolnej
>> przestrzeni trwa zbyt długo, i jest niepotrzebne...
>
> Są przeróżne erasery, które wymazują tylko kasowane pliki. Część wolna -
> np. http://eraser.heidi.ie/ ; przy czym pliki musisz kasować za ich
> pomocą. Nie spotkałem się z narzędziem, które po instalacji w systemie
> podmieniałoby standardową procedurę kasowania na wipowanie, niezależnie
> od systemu operacyjnego (w unixach musiałby być to raczej moduł do jądra
> przejmujący wywołania funkcji systemowych, w windows być może też).

Niekoniecznie. W większości przypadków wystarczyło by pomajstrować
w libc. Może nawet dało by się to załatwić tak jak to robi libsafe,
czyli przez preload odpowiedniej biblioteki.
Generalnie powinno to załatwić problem wszystkich aplikacji za wyjatkiem
statycznie polinkowanych (te trzeba by przekompilować) i tych które odwołują
się bezpośrednio do jądra (za dużo to takich nie ma).

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

bofh@nano.pl wrote:

> Lucjan J.A. Tumim wrote:
>>> a wymazywanie całej wolnej
>>> przestrzeni trwa zbyt długo, i jest niepotrzebne...
>> 
>> To ja się też zapytam. Jak skasować dane na wolnej przestrzeni w systemie
>> Linux.
>> 
> 
> cat /dev/urandom > /home/plik
> 
> Do komunikatu o zapchaniu dysku :)

A bardziej finezyjnie? Nie można zapchac całego dysku. trzeba zostawic 2% 
sam o tym dobrze wiesz.

	Lucjan J.A. Tumim [Lucjan2010@apoczta.fm.pl] 
  na: pl.comp.security napisał/ła:

>  bofh@nano.pl wrote:
> 
> > cat /dev/urandom > /home/plik
> > 
> > Do komunikatu o zapchaniu dysku :)
> 
>  A bardziej finezyjnie? Nie można zapchac całego dysku. trzeba zostawic 2% 
>  sam o tym dobrze wiesz.
Jak to nie można zapchać? tune2fs -m się kłania :) 


Pozdrawiam,
Ciacho


-- 
.:][              "Reszta jest tylko milczeniem..."                :.
.:][              -- TTC                                           :.

Dnia 2010-03-10 00:42, Użytkownik Konrad Stepien napisał:

> Niekoniecznie. W większości przypadków wystarczyło by pomajstrować
> w libc. Może nawet dało by się to załatwić tak jak to robi libsafe,
> czyli przez preload odpowiedniej biblioteki.

Czekaj, to chcesz powiedzieć, że open() i te POSIX-owe funkcje załatwia
libc a nie jądro? Bo fopen() to jeszcze rozumiem... W sumie nigdy się
nie zastanawiałem...

L.

Luke <luke@luke.net> napisał(a):
> Dnia 2010-03-10 00:42, Użytkownik Konrad Stepien napisał:
>
>> Niekoniecznie. W większości przypadków wystarczyło by pomajstrować
>> w libc. Może nawet dało by się to załatwić tak jak to robi libsafe,
>> czyli przez preload odpowiedniej biblioteki.
>
> Czekaj, to chcesz powiedzieć, że open() i te POSIX-owe funkcje załatwia
> libc a nie jądro? Bo fopen() to jeszcze rozumiem... W sumie nigdy się
> nie zastanawiałem...

To jest wtórne. Ważne jest, czy można przez preloadowaną bibliotekę
przechwycić taki syscall. Też nigdy tak głęboko nie wnikałem,
ale jaśli libsafe potrafi "intercepts calls to library functions",
to czemu by nie "interceptnąć" unlink-a.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

Konrad Stepien pisze:
> Luke <luke@luke.net> napisał(a):
>> Dnia 2010-03-10 00:42, Użytkownik Konrad Stepien napisał:
>>
>>> Niekoniecznie. W większości przypadków wystarczyło by pomajstrować
>>> w libc. Może nawet dało by się to załatwić tak jak to robi libsafe,
>>> czyli przez preload odpowiedniej biblioteki.
>> Czekaj, to chcesz powiedzieć, że open() i te POSIX-owe funkcje załatwia
>> libc a nie jądro? Bo fopen() to jeszcze rozumiem... W sumie nigdy się
>> nie zastanawiałem...
> 
> To jest wtórne. Ważne jest, czy można przez preloadowaną bibliotekę
> przechwycić taki syscall. Też nigdy tak głęboko nie wnikałem,
> ale jaśli libsafe potrafi "intercepts calls to library functions",
> to czemu by nie "interceptnąć" unlink-a.
> 
Żeby zapewnić kompatybilność aplikacje nie wykonują bezpośrednio 
syscalli tylko używają właśnie wywołań z libca. W libcu oidp są 
odpowiednie adresy oznaczone jako call gate więc koszt wywołania jest 
niewielki. Syscalla nie da się zastąpić z poziomu userspace, wywołanie 
biblioteczne - tak.

-- 
Pozdrawiam
Michoo

Tomasz T. Ciaszczyk wrote:

> Lucjan J.A. Tumim [Lucjan2010@apoczta.fm.pl]
>   na: pl.comp.security napisał/ła:
> 
>>  bofh@nano.pl wrote:
>> 
>> > cat /dev/urandom > /home/plik
>> > 
>> > Do komunikatu o zapchaniu dysku :)
>> 
>>  A bardziej finezyjnie? Nie można zapchac całego dysku. trzeba zostawic
>>  2% sam o tym dobrze wiesz.
> Jak to nie można zapchać? tune2fs -m się kłania :)

A jeszczede jakis program? Powiedzmy chce nadpisac kazde puste miejsce x 
razy

Michoo <michoo_news@vp.pl> napisał(a):
> Konrad Stepien pisze:
>> Luke <luke@luke.net> napisał(a):
>>> Dnia 2010-03-10 00:42, Użytkownik Konrad Stepien napisał:
>>>
>>>> Niekoniecznie. W większości przypadków wystarczyło by pomajstrować
>>>> w libc. Może nawet dało by się to załatwić tak jak to robi libsafe,
>>>> czyli przez preload odpowiedniej biblioteki.
>>> Czekaj, to chcesz powiedzieć, że open() i te POSIX-owe funkcje załatwia
>>> libc a nie jądro? Bo fopen() to jeszcze rozumiem... W sumie nigdy się
>>> nie zastanawiałem...
>> 
>> To jest wtórne. Ważne jest, czy można przez preloadowaną bibliotekę
>> przechwycić taki syscall. Też nigdy tak głęboko nie wnikałem,
>> ale jaśli libsafe potrafi "intercepts calls to library functions",
>> to czemu by nie "interceptnąć" unlink-a.
>> 
> Żeby zapewnić kompatybilność aplikacje nie wykonują bezpośrednio 
> syscalli tylko używają właśnie wywołań z libca. W libcu oidp są 
> odpowiednie adresy oznaczone jako call gate więc koszt wywołania jest 
> niewielki. Syscalla nie da się zastąpić z poziomu userspace, wywołanie 
> biblioteczne - tak.

Czyli dało by się taką bibliotekę popełnić i załatwiła by 99% przypadków.
Tylko, że jakoś nie trafiłem na ślad, żeby ktoś takie coś napisał.
A aż się prosi, żeby np. do shred-a takie coś dołożyć.
No, jeszcze przydało by się przechwytywać truncate.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

On Wed, 10 Mar 2010 18:31:43 +0100 Lucjan J.A. Tumim <Lucjan2010@apoczta.fm.pl> wrote:
> Tomasz T. Ciaszczyk wrote:
>> Lucjan J.A. Tumim [Lucjan2010@apoczta.fm.pl]
>>   na: pl.comp.security napisał/ła:
>>>  bofh@nano.pl wrote:
>>> > cat /dev/urandom > /home/plik
>>> > Do komunikatu o zapchaniu dysku :)
>>>  A bardziej finezyjnie? Nie można zapchac całego dysku. trzeba zostawic
>>>  2% sam o tym dobrze wiesz.
>> Jak to nie można zapchać? tune2fs -m się kłania :)
> A jeszczede jakis program? Powiedzmy chce nadpisac kazde puste miejsce x 
> razy

cat /dev/zero > plik
shred plik

- ewentualnie z opcjami.

R.
-- 
	Uniwersytet katolicki to oksymoron udający tautologię.

Rafał Maszkowski wrote:
> On Wed, 10 Mar 2010 18:31:43 +0100 Lucjan J.A. Tumim <Lucjan2010@apoczta.fm.pl> wrote:
>> Tomasz T. Ciaszczyk wrote:
>>> Lucjan J.A. Tumim [Lucjan2010@apoczta.fm.pl]
>>>   na: pl.comp.security napisał/ła:
>>>>  bofh@nano.pl wrote:
>>>>> cat /dev/urandom > /home/plik
>>>>> Do komunikatu o zapchaniu dysku :)
>>>>  A bardziej finezyjnie? Nie można zapchac całego dysku. trzeba zostawic
>>>>  2% sam o tym dobrze wiesz.
>>> Jak to nie można zapchać? tune2fs -m się kłania :)
>> A jeszczede jakis program? Powiedzmy chce nadpisac kazde puste miejsce x 
>> razy
> 
> cat /dev/zero > plik
> shred plik
> 
> - ewentualnie z opcjami.

/dev/zero nie jest najlepsze. Można odczytywać fizycznie z dysku co było
wcześniej zapisane. Zapisanie wartościami losowymi utrudnia taką operację.

wer

bofh@nano.pl <bofh@nano.pl> napisał(a):
> Rafa? Maszkowski wrote:
>> On Wed, 10 Mar 2010 18:31:43 +0100 Lucjan J.A. Tumim <Lucjan2010@apoczta.fm.pl> wrote:
>>> Tomasz T. Ciaszczyk wrote:
>>>> Lucjan J.A. Tumim [Lucjan2010@apoczta.fm.pl]
>>>>   na: pl.comp.security napisa?/?a:
>>>>>  bofh@nano.pl wrote:
>>>>>> cat /dev/urandom > /home/plik
>>>>>> Do komunikatu o zapchaniu dysku :)
>>>>>  A bardziej finezyjnie? Nie mo?na zapchac ca?ego dysku. trzeba zostawic
>>>>>  2% sam o tym dobrze wiesz.
>>>> Jak to nie mo?na zapcha?? tune2fs -m si? k?ania :)
>>> A jeszczede jakis program? Powiedzmy chce nadpisac kazde puste miejsce x 
>>> razy
>> 
>> cat /dev/zero > plik
>> shred plik
>> 
>> - ewentualnie z opcjami.
>
> /dev/zero nie jest najlepsze. Mo?na odczytywa? fizycznie z dysku co by?o
> wcze?niej zapisane. Zapisanie warto?ciami losowymi utrudnia tak? operacj?.

No to po to puszcza się shred-a.
Zrobi dużo więcej niż /dev/urandom

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

"bofh@nano.pl" <bofh@nano.pl> writes:

>> cat /dev/zero > plik
>> shred plik
>> 
>> - ewentualnie z opcjami.
>
> /dev/zero nie jest najlepsze. Można odczytywać fizycznie z dysku co było
> wcześniej zapisane. Zapisanie wartościami losowymi utrudnia taką operację.

A komus udalo sie odczytac poprzednia zawartosc w ciagu ostatnich 10
lat? Nie slyszalem, natomiast slyszalem opinie ludzi siedzacych w tym
temacie, ze to sie nie uda - normalny odczyt jest juz na granicy fizyki.

Mam wrazenie, ze ostatnio, to takie rzeczy byly demonstrowane na dyskach
MFM w latach 80.

Z drugiej strony, cat /dev/zero > plik niekoniecznie musi zniszczyc
dane, to troche zalezy od systemu plikow. Moze byc tak, ze na poczatku
truncate() zwolni bloki uzywane przez plik, a nastepnie zapis owszem,
zaalokuje bloki, ale zupelnie inne niz uzywane oryginalnie.

dd conv=notrunc, moze lepiej.
-- 
Krzysztof Halasa

On 2010-03-13, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "bofh@nano.pl" <bofh@nano.pl> writes:
>
>>> cat /dev/zero > plik
>>> shred plik
>>> 
>>> - ewentualnie z opcjami.
>>
>> /dev/zero nie jest najlepsze. Można odczytywać fizycznie z dysku co było
>> wcześniej zapisane. Zapisanie wartościami losowymi utrudnia taką operację.
>
> A komus udalo sie odczytac poprzednia zawartosc w ciagu ostatnich 10
> lat? Nie slyszalem, natomiast slyszalem opinie ludzi siedzacych w tym
> temacie, ze to sie nie uda - normalny odczyt jest juz na granicy fizyki.
>
> Mam wrazenie, ze ostatnio, to takie rzeczy byly demonstrowane na dyskach
> MFM w latach 80.
>
> Z drugiej strony, cat /dev/zero > plik niekoniecznie musi zniszczyc
> dane, to troche zalezy od systemu plikow. Moze byc tak, ze na poczatku
> truncate() zwolni bloki uzywane przez plik, a nastepnie zapis owszem,
> zaalokuje bloki, ale zupelnie inne niz uzywane oryginalnie.
>
> dd conv=notrunc, moze lepiej.

Nom, lepiej, ale nadal nie daje 100% pewności, że trafisz w te same
bloki. Na systemach z journalem ogólnie niewiele jest pewności co do
faktycznego miejsca zapisu (zwłaszcza z włączonym journalem danych, a
nie tylko metadanych).


-- 
Pozdrawiam,
Marek Marczykowski          |   gg:2873965      | RLU #390519
marmarek at staszic waw pl  | xmpp:marmarek at staszic waw pl
http://akademia.linuksa.pl - Szkolenia Linux, PHP, Java, Office

Marek Marczykowski <marmarek@spam.nie> writes:

>> dd conv=notrunc, moze lepiej.
>
> Nom, lepiej, ale nadal nie daje 100% pewności, że trafisz w te same
> bloki. Na systemach z journalem ogólnie niewiele jest pewności co do
> faktycznego miejsca zapisu (zwłaszcza z włączonym journalem danych, a
> nie tylko metadanych).

To tez zalezy od systemu plikow, ale akurat w tradycyjnych nie ma
realokacji w takim przypadku. Tzn. dane przechodza przez dziennik, ale
trafiaja w koncu tam, gdzie maja trafic.
-- 
Krzysztof Halasa

Konrad Stepien <xbaenq@vagreqngn.arg.cy> wrote:
> Czyli dało by się taką bibliotekę popełnić i załatwiła by 99% przypadków.

To juz lepiej modul do jadra, ktory wlasnie przechwyci, co trzeba
i nadpisze za kazdym razem, bez ogladania sie na biblioteki. :)

p.

-- 
http://freedns.sgh.waw.pl/  -- bezpłatny DNS.
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów.
http://42.pl/u/ -- skracacz URL-i.

Piotr KUCHARSKI <chopin@sgh.waw.pl> napisał(a):
> Konrad Stepien <xbaenq@vagreqngn.arg.cy> wrote:
>> Czyli da?o by si? tak? bibliotek? pope?ni? i za?atwi?a by 99% przypadków.
>
> To juz lepiej modul do jadra, ktory wlasnie przechwyci, co trzeba
> i nadpisze za kazdym razem, bez ogladania sie na biblioteki. :)

Pewnie że lepiej, ale wtedy będzie linux-specyfic no i przy każdym
upgradzie jądra trzeba będzie kombinować.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>