On Thu, 30 Jan 2020 at 05:26, Moritz Mühlenhoff wrote:
> I'm in favour of setting both to 1. From a quick search Ubuntu carried a
> patch
> in their systemd package to set this as well (LP 1845637).
>
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so
* Richard Laager [200129 19:05]:
> On 1/29/20 8:28 AM, Marvin Renich wrote:
> There are plenty of shades of
> grey in this, and what counts as "minimal", "medium", or "massive" is
> going to be at least somewhat subjective.
Completely agree.
> I'd say that "massive breakage" (breaking lots of
[ Note: I have reordered the quoted text blocks. ]
On 1/29/20 8:28 AM, Marvin Renich wrote:
> On the other hand, I do agree with using unstable and testing to
> determine the level of disruption, on the condition that there is a
> _commitment_ to removing the feature before stable release if the
On Wed, 2020-01-29 at 10:13 -0800, Moritz Mühlenhoff wrote:
> Craig Small schrieb:
> > --4806c5059d3edeb1
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi,
> > About 2 years ago the procps package added protection for hard and soft
> > symlinks. The bug report was 889098
Craig Small schrieb:
> --4806c5059d3edeb1
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
> About 2 years ago the procps package added protection for hard and soft
> symlinks. The bug report was 889098 and has seemed to work fine.
>
> There is also now bug #914859 which would
I have no opinion about this specific feature; at first glance it looks
like it might be a reasonable thing to do. On the other hand, I
strongly disagree with this statement as a general rule:
> Unless massive breakage is expected, the default should
> be the most secure option.
This is the
On 1/28/20 9:23 PM, Craig Small wrote:
> My personal preference is to lock them down by default, by setting both
> to mode 2.
FWIW: I agree. Unless massive breakage is expected, the default should
be the most secure option. If you default to secure and that breaks
something, people will be
Hi,
About 2 years ago the procps package added protection for hard and soft
symlinks. The bug report was 889098 and has seemed to work fine.
There is also now bug #914859 which would extend this same protection for
other files, as mentioned in [1]
On the one hand, having all these file types
8 matches
Mail list logo
