executable ELF is rm-ed from disk, but still running RAM..

executable ELF is rm-ed from disk, but still running RAM..

[Mulyadi Santosa]

Hi all..

As the subject says, I was thinking about that issue.

I know that rm-ing a file doesn't delete the data block from the
backing device, thus the executable could still survive and running.

But logically, we usually expect that once a file is rm-ed, it should
also "stop", right? What does POSIX say about this case anyway? Anyone
could kindly give his/her opinion?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

executable ELF is rm-ed from disk, but still running RAM..

[Jonathan Neuschäfer]

On Mon, May 30, 2011 at 09:49:29PM +0700, Mulyadi Santosa wrote:
> Hi all..
> 
> As the subject says, I was thinking about that issue.
> 
> I know that rm-ing a file doesn't delete the data block from the
> backing device, thus the executable could still survive and running.
> 
> But logically, we usually expect that once a file is rm-ed, it should
> also "stop", right? What does POSIX say about this case anyway? Anyone
> could kindly give his/her opinion?

I think the point is that the file is still "open", i.e. mapped into the
the processes virtual memory, and thus the inode whose seemingly last
reference you've just removed is still referenced.

I'm guessing that from unlink(2): "If the name was the last link to a
file but any processes still have the file open the file will remain in
existence until the last file descriptor referring to it is closed." A
mapping is not a file desciptor but I believe that it behaves similiarly.

But I'm not sure.

Thanks,
	Jonathan Neusch?fer

executable ELF is rm-ed from disk, but still running RAM..

[Pei Lin]

2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
> Hi all..
>
> As the subject says, I was thinking about that issue.
>
> I know that rm-ing a file doesn't delete the data block from the
> backing device, thus the executable could still survive and running.
>
> But logically, we usually expect that once a file is rm-ed, it should
> also "stop", right? What does POSIX say about this case anyway? Anyone
> could kindly give his/her opinion?
In my view, i don't expect that rm one file should also stop the
related process. If that, in one system, do the thing "rm sysfile"
will stop OS running? In my logic, i just think run the executable is
the user's choice before "rm it", if the user want to delete file,
also who want to stop the process related this file should kill the
process themselves. I consider that if the users delete one file
uncarefully, should give the chance to recover it and not block
current running task.

>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Best Regards
Lin

executable ELF is rm-ed from disk, but still running RAM..

[Mulyadi Santosa]

Hi all..


On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@gmail.com> wrote:
> 2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
>> Hi all..
>>
>> As the subject says, I was thinking about that issue.
>>
>> I know that rm-ing a file doesn't delete the data block from the
>> backing device, thus the executable could still survive and running.
>>
>> But logically, we usually expect that once a file is rm-ed, it should
>> also "stop", right? What does POSIX say about this case anyway? Anyone
>> could kindly give his/her opinion?
> In my view, i don't expect that rm one file should also stop the
> related process. If that, in one system, do the thing "rm sysfile"
> will stop OS running? In my logic, i just think run the executable is
> the user's choice before "rm it", if the user want to delete file,
> also who want to stop the process related this file should kill the
> process themselves. I consider that if the users delete one file
> uncarefully, should give the chance to recover it and not block
> current running task.


Thanks for sharing your thoughts so far. This came to my mind when I
did a project about 2 years ago. At that time, I also came to very
much same conclusion: if you want to make sure new binary is executed,
sigkill/sigterm the old ones first, remove them and run the new one.
Seems trivial, but initially this tiny little detail missed from my
mind.


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

executable ELF is rm-ed from disk, but still running RAM..

[Manish Katiyar]

On Mon, May 30, 2011 at 7:46 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Hi all..
>
>
> On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@gmail.com> wrote:
>> 2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
>>> Hi all..
>>>
>>> As the subject says, I was thinking about that issue.
>>>
>>> I know that rm-ing a file doesn't delete the data block from the
>>> backing device, thus the executable could still survive and running.
>>>
>>> But logically, we usually expect that once a file is rm-ed, it should
>>> also "stop", right? What does POSIX say about this case anyway? Anyone
>>> could kindly give his/her opinion?
>> In my view, i don't expect that rm one file should also stop the
>> related process. If that, in one system, do the thing "rm sysfile"
>> will stop OS running? In my logic, i just think run the executable is
>> the user's choice before "rm it", if the user want to delete file,
>> also who want to stop the process related this file should kill the
>> process themselves. I consider that if the users delete one file
>> uncarefully, should give the chance to recover it and not block
>> current running task.
>
>
> Thanks for sharing your thoughts so far. This came to my mind when I
> did a project about 2 years ago. At that time, I also came to very
> much same conclusion: if you want to make sure new binary is executed,
> sigkill/sigterm the old ones first, remove them and run the new one.
> Seems trivial, but initially this tiny little detail missed from my
> mind.

How will "rm /bin/rm" work otherwise ?

-- 
Thanks -
Manish

executable ELF is rm-ed from disk, but still running RAM..

[Mulyadi Santosa]

hi..

On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com> wrote:
> How will "rm /bin/rm" work otherwise ?

ok, makes me think another case....suppose we erase the related data
blocks in the disk that correlate to running binary.... does Linux
kernel follow that with erasing all the related page cache? or is it
possible that temporarily cache of the disk blocks still survived?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

executable ELF is rm-ed from disk, but still running RAM..

[Manish Katiyar]

On Mon, May 30, 2011 at 8:45 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> hi..
>
> On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com> wrote:
>> How will "rm /bin/rm" work otherwise ?
>
> ok, makes me think another case....suppose we erase the related data
> blocks in the disk that correlate to running binary.... does Linux
> kernel follow that with erasing all the related page cache? or is it
> possible that temporarily cache of the disk blocks still survived?

I don't know for sure, but my guess is that the OS wouldn't notice it
till it goes out of cache and it has to reload.

-- 
Thanks -
Manish

executable ELF is rm-ed from disk, but still running RAM..

[Vikash Kumar]

AFAIK Linux removes the directory entry and reduces the reference count of
Inode of a running process and rm is successful. So, you can't see it in the
file system anymore. However as the program is still running the inode
reference count is still not zero and so the Inode and hence file is
actually not deleted yet. When the program will terminate, Inode ref count
will drop to zero and in that case the Inode and file will be freed.

"The design of Unix Operating System" by Maurice J. Bach It covers these
basic design principles in good detail.


On Tue, May 31, 2011 at 10:12 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:

> On Mon, May 30, 2011 at 8:45 PM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > hi..
> >
> > On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com>
> wrote:
> >> How will "rm /bin/rm" work otherwise ?
> >
> > ok, makes me think another case....suppose we erase the related data
> > blocks in the disk that correlate to running binary.... does Linux
> > kernel follow that with erasing all the related page cache? or is it
> > possible that temporarily cache of the disk blocks still survived?
>
> I don't know for sure, but my guess is that the OS wouldn't notice it
> till it goes out of cache and it has to reload.
>
> --
> Thanks -
> Manish
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110531/fe0eda3a/attachment-0001.html 

executable ELF is rm-ed from disk, but still running RAM..

[Mulyadi Santosa]

On Tue, May 31, 2011 at 11:56, Vikash Kumar <vikashskumar@gmail.com> wrote:
> AFAIK Linux removes the directory entry and reduces the reference count of
> Inode of a running process and rm is successful. So, you can't see it in the
> file system anymore. However as the program is still running the inode
> reference count is still not zero and so the Inode and hence file is
> actually not deleted yet. When the program will terminate, Inode ref count
> will drop to zero and in that case the Inode and file will be freed.
> "The design of Unix Operating System" by Maurice J. Bach It covers these
> basic design principles in good detail.

Thanks people...you put valuable feedback to me. It's good to see I am
around knowledgeable people :)

As for the deletion case, I might do further research to see how the
very recent Linux kernel behaves. Hopefully, if the time permits...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com