10.11.2017, 22:06, "valdis.kletnieks@xxxxxx" <valdis.kletnieks@xxxxxx>:
> On Fri, 10 Nov 2017 21:04:22 +0300, Lev Olshvang said:
>
>> I am going to patch inode reference count of mapped shared libs
>
> Congrats. You just corrupted your file system.
>
> Hint 1: What happens if you decrement the count by one unnecessarily,
> and later on, probably during system shutdown, the reference count drops
> to zero instead of one?
>
> Hint 2: What happens if you incremented the count, and at system shutdown,
> there's still a reference left when the kernel tries to unmount and sync the
> filesystem?
> ,
>
Hi Valdis ,
Now you make things more clearly to me and I start to see the problem.
The difference between executable and file that executable may crash. while
shared lib can not.
Still there are unknown for me what happen with opened files and mmaped files when crash occurs
I used to think that kernel decrease reference counts and closes files, whether application exits normally or crashed.
Now I add some facts about executables from kernel code:
fss/binfmt_misc.c: deny_write_access(interp_file);
fs/exec.c: err = deny_write_access(file);
fs/exec.c: ret = deny_write_access(file);
And I found following explanatioin in old kernel list archive:
The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
> > excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
> > and even root cannot write to it.. Vary nasty.
> > excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
> > and even root cannot write to it.. Vary nasty.
And I still confused because shared libraries are mapped with PROT_EXEC flag and so they differ
from regular file like /etc/passwd and generally have -r-x file system permissions.
Regards,
Lev
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
