* core(5)
@ 2020-06-06 13:18 Jonny Grant
2020-06-06 14:50 ` core(5) Jakub Wilk
2020-06-08 16:06 ` core(5) Michael Kerrisk (man-pages)
0 siblings, 2 replies; 8+ messages in thread
From: Jonny Grant @ 2020-06-06 13:18 UTC (permalink / raw)
To: Michael Kerrisk, linux-man
Hello
Some feedback on this page
https://man7.org/linux/man-pages/man5/core.5.html
1) "disk file" sounds rather old fashioned, usually would just say "file", on this page, removing the word "disk"
"The default action of certain signals is to cause a process to
terminate and produce a /core dump file/, a disk file containing an"
2) We wouldn't regularly say "nonwritable" in English, "not writeable" is better English
3) Could i ask to clarify my understanding. For this "The binary being executed by the process does not have read
permission enabled."
-- is this when the binary permissions are changed after it starts running?
I thought a core file was just a dump from RAM, does it really even need to open the ELF file again?
4) I noticed %P always gave me P1200 even after a reboot I recall, I had expected it be '1', do you see similar?
Cheers, Jonny
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 13:18 core(5) Jonny Grant
@ 2020-06-06 14:50 ` Jakub Wilk
2020-06-06 15:45 ` core(5) Jonny Grant
2020-06-08 16:06 ` core(5) Michael Kerrisk (man-pages)
1 sibling, 1 reply; 8+ messages in thread
From: Jakub Wilk @ 2020-06-06 14:50 UTC (permalink / raw)
To: Jonny Grant; +Cc: Michael Kerrisk, linux-man
* Jonny Grant <jg@jguk.org>, 2020-06-06, 14:18:
>3) Could i ask to clarify my understanding. For this "The binary being
>executed by the process does not have read
> permission enabled."
>-- is this when the binary permissions are changed after it starts
>running?
No, AFAICS the permission check is done when the process starts.
>4) I noticed %P always gave me P1200 even after a reboot I recall, I
>had expected it be '1', do you see similar?
Here %P expands to the pid of the process, as expected:
$ uname -rv
5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23)
$ sudo sysctl -w kernel.core_pattern="%P-%e-%s.core"
kernel.core_pattern = %P-%e-%s.core
$ ulimit -c unlimited
$ sh -c 'kill -ABRT $$'
Aborted (core dumped)
$ ls *.core
7154-sh-6.core
--
Jakub Wilk
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 14:50 ` core(5) Jakub Wilk
@ 2020-06-06 15:45 ` Jonny Grant
2020-06-06 18:32 ` core(5) Jakub Wilk
0 siblings, 1 reply; 8+ messages in thread
From: Jonny Grant @ 2020-06-06 15:45 UTC (permalink / raw)
To: Jakub Wilk; +Cc: Michael Kerrisk, linux-man
On 06/06/2020 15:50, Jakub Wilk wrote:
> * Jonny Grant <jg@jguk.org>, 2020-06-06, 14:18:
>> 3) Could i ask to clarify my understanding. For this "The binary being executed by the process does not have read
>> permission enabled."
>> -- is this when the binary permissions are changed after it starts running?
>
> No, AFAICS the permission check is done when the process starts.
How can the process start if the binary file doesn't have read permissions enabled?
>> 4) I noticed %P always gave me P1200 even after a reboot I recall, I had expected it be '1', do you see similar?
>
> Here %P expands to the pid of the process, as expected:
>
> $ uname -rv
> 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23)
>
> $ sudo sysctl -w kernel.core_pattern="%P-%e-%s.core"
> kernel.core_pattern = %P-%e-%s.core
>
> $ ulimit -c unlimited
>
> $ sh -c 'kill -ABRT $$'
> Aborted (core dumped)
>
> $ ls *.core
> 7154-sh-6.core
My apologies, it was P1000. This was from two different runs, 2 days apart.
I think this was "P%P-T%i%e-%s-T%t". I tried to reproduce today, but couldn't
-rw------- 1 jonny jonny 99041280 May 27 21:42 P1000-T18441Process-5-T1590612166.core
-rw------- 1 jonny jonny 104407040 May 29 23:24 P1000-T5804Process-5-T1590791098.core
Cheers, Jonny
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 15:45 ` core(5) Jonny Grant
@ 2020-06-06 18:32 ` Jakub Wilk
2020-06-06 19:39 ` core(5) Michael Kerrisk (man-pages)
0 siblings, 1 reply; 8+ messages in thread
From: Jakub Wilk @ 2020-06-06 18:32 UTC (permalink / raw)
To: Jonny Grant; +Cc: Michael Kerrisk, linux-man
* Jonny Grant <jg@jguk.org>, 2020-06-06, 16:45:
>>>3) Could i ask to clarify my understanding. For this "The binary
>>>being executed by the process does not have read permission enabled."
>>>-- is this when the binary permissions are changed after it starts
>>>running?
>>No, AFAICS the permission check is done when the process starts.
>How can the process start if the binary file doesn't have read
>permissions enabled?
It's a bit weird, but the kernel doesn't mind:
$ cp /bin/ls .
$ chmod a-r ls
$ ./ls -l ls
--wx--x--x 1 jwilk jwilk 138856 Jun 6 20:22 ls
--
Jakub Wilk
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 18:32 ` core(5) Jakub Wilk
@ 2020-06-06 19:39 ` Michael Kerrisk (man-pages)
2020-06-06 21:16 ` core(5) Jonny Grant
0 siblings, 1 reply; 8+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-06-06 19:39 UTC (permalink / raw)
To: Jakub Wilk; +Cc: Jonny Grant, linux-man
On Sat, 6 Jun 2020 at 20:32, Jakub Wilk <jwilk@jwilk.net> wrote:
>
> * Jonny Grant <jg@jguk.org>, 2020-06-06, 16:45:
> >>>3) Could i ask to clarify my understanding. For this "The binary
> >>>being executed by the process does not have read permission enabled."
> >>>-- is this when the binary permissions are changed after it starts
> >>>running?
> >>No, AFAICS the permission check is done when the process starts.
> >How can the process start if the binary file doesn't have read
> >permissions enabled?
>
> It's a bit weird, but the kernel doesn't mind:
>
> $ cp /bin/ls .
> $ chmod a-r ls
> $ ./ls -l ls
> --wx--x--x 1 jwilk jwilk 138856 Jun 6 20:22 ls
And from core(5):
There are various circumstances in which a core dump file is not
produced:
...
* The binary being executed by the process does not have read
permission enabled.
So, the binary can be executed, but not read, and will not do a core
dump (since that might be readable).
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 19:39 ` core(5) Michael Kerrisk (man-pages)
@ 2020-06-06 21:16 ` Jonny Grant
2020-06-08 16:18 ` core(5) Michael Kerrisk (man-pages)
0 siblings, 1 reply; 8+ messages in thread
From: Jonny Grant @ 2020-06-06 21:16 UTC (permalink / raw)
To: mtk.manpages, Jakub Wilk; +Cc: linux-man
On 06/06/2020 20:39, Michael Kerrisk (man-pages) wrote:
> On Sat, 6 Jun 2020 at 20:32, Jakub Wilk <jwilk@jwilk.net> wrote:
>>
>> * Jonny Grant <jg@jguk.org>, 2020-06-06, 16:45:
>>>>> 3) Could i ask to clarify my understanding. For this "The binary
>>>>> being executed by the process does not have read permission enabled."
>>>>> -- is this when the binary permissions are changed after it starts
>>>>> running?
>>>> No, AFAICS the permission check is done when the process starts.
>>> How can the process start if the binary file doesn't have read
>>> permissions enabled?
>>
>> It's a bit weird, but the kernel doesn't mind:
>>
>> $ cp /bin/ls .
>> $ chmod a-r ls
>> $ ./ls -l ls
>> --wx--x--x 1 jwilk jwilk 138856 Jun 6 20:22 ls
>
> And from core(5):
>
> There are various circumstances in which a core dump file is not
> produced:
> ...
> * The binary being executed by the process does not have read
> permission enabled.
>
> So, the binary can be executed, but not read, and will not do a core
> dump (since that might be readable).
>
> Thanks,
>
> Michael
Hi Michael, Jakub,
It sounds like a good security feature. Could that be documented on the man page as the reason?
ie something like this:
* The binary being executed by the process does not have read
permission enabled, therefore a core file would reveal information in a readable file, so it cannot be dumped.
Cheers
Jonny
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 21:16 ` core(5) Jonny Grant
@ 2020-06-08 16:18 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 8+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-06-08 16:18 UTC (permalink / raw)
To: Jonny Grant, Jakub Wilk; +Cc: mtk.manpages, linux-man
Hi Jonny,
On 6/6/20 11:16 PM, Jonny Grant wrote:
>
>
> On 06/06/2020 20:39, Michael Kerrisk (man-pages) wrote:
>> On Sat, 6 Jun 2020 at 20:32, Jakub Wilk <jwilk@jwilk.net> wrote:
>>>
>>> * Jonny Grant <jg@jguk.org>, 2020-06-06, 16:45:
>>>>>> 3) Could i ask to clarify my understanding. For this "The binary
>>>>>> being executed by the process does not have read permission enabled."
>>>>>> -- is this when the binary permissions are changed after it starts
>>>>>> running?
>>>>> No, AFAICS the permission check is done when the process starts.
>>>> How can the process start if the binary file doesn't have read
>>>> permissions enabled?
>>>
>>> It's a bit weird, but the kernel doesn't mind:
>>>
>>> $ cp /bin/ls .
>>> $ chmod a-r ls
>>> $ ./ls -l ls
>>> --wx--x--x 1 jwilk jwilk 138856 Jun 6 20:22 ls
>>
>> And from core(5):
>>
>> There are various circumstances in which a core dump file is not
>> produced:
>> ...
>> * The binary being executed by the process does not have read
>> permission enabled.
>>
>> So, the binary can be executed, but not read, and will not do a core
>> dump (since that might be readable).
>>
>> Thanks,
>>
>> Michael
>
> Hi Michael, Jakub,
>
> It sounds like a good security feature. Could that be documented on the man page as the reason?
>
> ie something like this:
>
> * The binary being executed by the process does not have read
> permission enabled, therefore a core file would reveal information in
> a readable file, so it cannot be dumped.
Thanks for the suggested wording. I applied the patch below.
Thanks,
Michael
diff --git a/man5/core.5 b/man5/core.5
index 456366ea6..0d7b7b617 100644
--- a/man5/core.5
+++ b/man5/core.5
@@ -90,6 +90,10 @@ in
.IP *
The binary being executed by the process does not have read
permission enabled.
+(This is a security measure to
+ensure that an executable whose contents are not readable
+does not produce a\(empossibly readable\(emcore dump containing
+an image of the executable.)
.IP *
The process is executing a set-user-ID (set-group-ID) program
that is owned by a user (group) other than the real user (group)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: core(5)
2020-06-06 13:18 core(5) Jonny Grant
2020-06-06 14:50 ` core(5) Jakub Wilk
@ 2020-06-08 16:06 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 8+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-06-08 16:06 UTC (permalink / raw)
To: Jonny Grant, linux-man; +Cc: mtk.manpages
Hell Jonny
On 6/6/20 3:18 PM, Jonny Grant wrote:
> Hello
>
> Some feedback on this page
> https://man7.org/linux/man-pages/man5/core.5.html
>
> 1) "disk file" sounds rather old fashioned, usually would just say
> "file", on this page, removing the word "disk"
>
> "The default action of certain signals is to cause a process to
> terminate and produce a /core dump file/, a disk file containing an"
>
> 2) We wouldn't regularly say "nonwritable" in English, "not
> writeable" is better English
I did some rewording for both of these.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-06-08 16:18 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-06 13:18 core(5) Jonny Grant
2020-06-06 14:50 ` core(5) Jakub Wilk
2020-06-06 15:45 ` core(5) Jonny Grant
2020-06-06 18:32 ` core(5) Jakub Wilk
2020-06-06 19:39 ` core(5) Michael Kerrisk (man-pages)
2020-06-06 21:16 ` core(5) Jonny Grant
2020-06-08 16:18 ` core(5) Michael Kerrisk (man-pages)
2020-06-08 16:06 ` core(5) Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).