core(5)

core(5)

[Jonny Grant]

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

Re: core(5)

[Jakub Wilk]

* 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

Re: core(5)

[Jonny Grant]

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

Re: core(5)

[Jakub Wilk]

* 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

Re: core(5)

[Michael Kerrisk (man-pages)]

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/

Re: core(5)

[Jonny Grant]

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

Re: core(5)

[Michael Kerrisk (man-pages)]

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/

Re: core(5)

[Michael Kerrisk (man-pages)]

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/