On Tue, 14 Nov 2017 14:18:42 +0300, Lev Olshvang said:
The difference between executable and file that executable may crash. while shared lib can not.
Oh, a shared lib can indeed crash (or more correctly cause a crash in the process that is using it).
Still there are unknown for me what happen with opened files and mmaped files when crash occurs
Same thing as an executable or a mapped shared library (.so's are just mmap() under the covers), Reference counts are reference counts.
I used to think that kernel decrease reference counts and closes files, whether application exits normally or crashed.
Right. And you change those reference counts on your own at your own peril.
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: https://lists.gt.net/linux/kernel/222875 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.
Right - so DENYWRITE is restricted to executables (where it makes sense anyhow) However, shared libraries are just mmap() - so there's no easy way to say "only allow DENYWRITE for .so images". (Hint - a shared library doesn't have to be called something.so - and in fact is usually 'something.so.versionstring")
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.
Actually, most shared libraries will end up with several mmap() segments - one for .txt, one for .bss (uninitialized variables), and one for .data (initialized variables) - and they will be mapped with different flags. Do an 'strace /bin/echo foo' and ponder what actually happens.