On Fri, 05 Apr 2019 11:58:24 +0800 Paul Wise wrote:
> I've done that in the attached patch.
I've now asked the release team for an unblock.
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
On Thu, 21 Mar 2019 10:17:30 +0800 Paul Wise wrote:
> Do you have any suggestions for how to deal with the postinst
> permissions update? I'm guessing it should just update the permissions
> on upgrade between the two versions and not if a statoverride is set?
I've done that in the attached
On Wed, 13 Mar 2019 20:31:12 +0800 Paul Wise wrote:
> Hmm, so the upgrade has to deal with that automatically in a variety of
> situations. This is going to be annoying, maybe it should just change
> the permissions in the postinst based on the core pattern sysctl?
Do you have any suggestions
* Paul Wise , 2019-03-15, 08:59:
As a data point, apport creates /var/crash as world-writable in
postinst:
Does apport use a core dump handler?
Yes.
If so it shouldn't need a world writable directory since the core dump
handler runs as root.
Apparmor saves dumps directly in /var/crash
On Thu, 2019-03-14 at 12:12 +0100, Jakub Wilk wrote:
> As a data point, apport creates /var/crash as world-writable in postinst:
Does apport use a core dump handler? If so it shouldn't need a world
writable directory since the core dump handler runs as root.
corekeeper and apport conflict so
As a data point, apport creates /var/crash as world-writable in postinst:
if [ "$1" = configure ]; then
# directory is required for package failures even if apport is disabled
mkdir -p -m 1777 /var/crash
fi
And it chmods it in the init script:
chmod 1777 /var/crash
OTOH,
On 2019-03-13 20:29 +0800, Paul Wise wrote:
> On Wed, 2019-03-13 at 13:11 +0100, Jakub Wilk wrote:
>
>> Also, it looks like dpkg doesn't update directory permissions on
>> upgrade. Ugh. :-(
>
> dpkg maintainers, do you know if this is a known bug or intentional?
Both, see #515211[1].
Cheers,
On Wed, 2019-03-13 at 13:11 +0100, Jakub Wilk wrote:
> Also, it looks like dpkg doesn't update directory permissions on
> upgrade. Ugh. :-(
dpkg maintainers, do you know if this is a known bug or intentional?
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is
On Wed, 2019-03-13 at 13:11 +0100, Jakub Wilk wrote:
> This never does anything, because closing square bracket is missing:
Fixed locally.
> Also, it looks like dpkg doesn't update directory permissions on
> upgrade. Ugh. :-(
Hmm, so the upgrade has to deal with that automatically in a
+ if [ ! -e $(script) ; then chmod 1777 debian/corekeeper/var/crash ; fi
This never does anything, because closing square bracket is missing:
/bin/sh: 1: [: missing ]
Also, it looks like dpkg doesn't update directory permissions on
upgrade. Ugh. :-(
--
Jakub Wilk
Control: tags -1 + patch
On Wed, 13 Mar 2019 08:16:16 +0800 Paul Wise wrote:
> On Tue, 2019-03-12 at 15:50 +0100, Jakub Wilk wrote:
>
> > I don't understand why /var/crash is world-writable
>
> I guess that is for when the core dump handler is unused and probably I
> forgot to change it when
On Tue, 2019-03-12 at 15:50 +0100, Jakub Wilk wrote:
> I don't understand why /var/crash is world-writable
I guess that is for when the core dump handler is unused and probably I
forgot to change it when switching to the core dump handler.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Package: corekeeper
Version: 1.6
Severity: critical
Tags: security
(I reported this privately in 2016...)
/usr/lib/corekeeper/dump does this:
mkdir -p "/var/crash/$owner"
This is pretty bad. /var/crash is word-writable, so anybody could have
created a subdirectory there. "mkdir -p" will
13 matches
Mail list logo
