[issue950] Coredumping design error

[Eduardo Tongson]

Hello Matt,

p->p_ucred->cr_uid is equal to the user/group ID of the process right?
I think it will work.

Ed

On Feb 17, 2008 2:05 AM, Matthew Dillon <bugs at lists.dragonflybsd.org> wrote:
>
> Matthew Dillon <dillon at apollo.backplane.com> added the comment:
>
>
> :Hello Simon,
> :
> :In my opinion checking for ownership is better. We are avoiding other
> :possible(?) bugs e.g. allowing to read files you don't own but resides
> :on a directory you own. I also noticed that non-root users trying to
> :coredump on other non-root users pre-created dumps fail silently.
> :
> :By the way as seen in my patch, we wouldn't want to hard code != 0
> :because DragonFly may implement a type enforcement system or
> :authorization framework.
> :
> :Up to you guys. I might be missing something.
> :
> :Cheers,
> :   Ed
>
>     Yes, I agree, we definitely do not want to remove the file.  The reason
>     is that it is possible (and likely) that a service process that forks
>     may coredump multiple times, possibly even in parallel.  Possibly
>     hundreds of times in parallel.  This is one reason why the coredump
>     code gets an advisory lock on the file.
>
>     My only question re: this patch is whether it will work properly
>     with sysctl kern.sugid_coredump.
>
>                                                 -Matt
>
>
> _____________________________________________________
> DragonFly issue tracker <bugs at lists.dragonflybsd.org>
> <https://bugs.dragonflybsd.org/issue950>
> _____________________________________________________
>