Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* 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 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

* 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	[flat|nested] 8+ messages in thread

end of thread, back to index

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)

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git