<div> </div><div> </div><div>10.11.2017, 22:06, "valdis.kletnieks@vt.edu" &lt;valdis.kletnieks@vt.edu&gt;:</div><div>&gt; On Fri, 10 Nov 2017 21:04:22 +0300, Lev Olshvang said:</div><div>&gt;</div><div>&gt;&gt;  I am going to patch inode reference count of mapped shared libs</div><div>&gt;</div><div>&gt; Congrats. You just corrupted your file system.</div><div>&gt;</div><div>&gt; Hint 1: What happens if you decrement the count by one unnecessarily,</div><div>&gt; and later on, probably during system shutdown, the reference count drops</div><div>&gt; to zero instead of one?</div><div>&gt;</div><div>&gt; Hint 2: What happens if you incremented the count, and at system shutdown,</div><div>&gt; there's still a reference left when the kernel tries to unmount and sync the</div><div>&gt; filesystem?</div><div>&gt; ,</div><div>&gt;</div><div> </div><div>Hi Valdis ,</div><div> </div><div>Now you make things more clearly to me and I start to see the problem.</div><div> </div><div>The difference between executable and file that executable may crash. while</div><div>shared lib can not.</div><div> </div><div>Still there are unknown for me what happen with  opened files and mmaped files  when crash occurs</div><div> </div><div>I used to think that kernel  decrease reference counts and closes files, whether application exits normally or crashed.</div><div> </div><div> </div><div>Now I add some facts about executables from kernel code:</div><div><div>fss/binfmt_misc.c:                       deny_write_access(interp_file);</div><div>fs/exec.c:      err = deny_write_access(file);</div><div>fs/exec.c:      ret = deny_write_access(file);</div><div> </div><div>And I found following explanatioin in old kernel list archive:</div><div><a href="https://lists.gt.net/linux/kernel/222875">https://lists.gt.net/linux/kernel/222875</a></div><div> </div><div><span style="background-color:#f6f6f6;color:#007777;display:inline !important;float:none;font-family:lato,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:normal;text-align:start;text-transform:none;white-space:normal;">The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an<span> </span></span><br style="color:rgb(0,119,119);font-family:Lato,Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;text-align:start;text-transform:none;white-space:normal;background-color:rgb(246,246,246);" /><span style="background-color:#f6f6f6;color:#007777;display:inline !important;float:none;font-family:lato,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:normal;text-align:start;text-transform:none;white-space:normal;">&gt; &gt; excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,<span> </span></span><br style="color:rgb(0,119,119);font-family:Lato,Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;text-align:start;text-transform:none;white-space:normal;background-color:rgb(246,246,246);" /><span style="background-color:#f6f6f6;color:#007777;display:inline !important;float:none;font-family:lato,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:normal;text-align:start;text-transform:none;white-space:normal;">&gt; &gt; and even root cannot write to it.. Vary nasty.<span> </span></span></div><div> </div><div> </div><div>And I still confused because shared libraries are mapped with PROT_EXEC flag and so they differ</div><div>from regular file like /etc/passwd and generally have -r-x file system permissions.</div><div> </div><div> </div><div>Regards,</div><div>Lev</div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div></div><div> </div><div> </div><div> </div><div> </div><div> </div><div> </div>