Hi,
As part of a prototype I'm working on to run systemd within an unprivileged
docker container, I would like to prevent mountpoints created at runtime
from being unmounted during the container shutdown process. I understand
that systemd creates ".mount" units dynamically for
these mountpoints
On 20/02/2021 00:30, Lennart Poettering wrote:
The fallback servers are only used as last resort, if there's nothing
else known. They are *fallback* as the name says.
Most likely the DNS servers were acquire by your network management
solution (NetworkManager or networkd) and set on the device.
On Fri, Feb 19, 2021 at 06:09:16PM +0200, Mantas Mikulėnas wrote:
> On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering
> wrote:
>
> > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > > i guess i expected that the CVE identifier would be in the commit
> > > message.
Am 19.02.21 um 21:05 schrieb Frank Thommen:
Lennart Poettering hat am 19.02.2021 15:44 geschrieben:
On Fr, 19.02.21 15:12, Frank Thommen (systemd-de...@lists.drosera.ch) wrote:
Dear all,
I am experiencing the issue, that an unprivileged user can kill
root-owned processes by
> Lennart Poettering hat am 19.02.2021 15:44
> geschrieben:
>
>
> On Fr, 19.02.21 15:12, Frank Thommen (systemd-de...@lists.drosera.ch) wrote:
>
> > Dear all,
> >
> > I am experiencing the issue, that an unprivileged user can kill
> > root-owned processes by changing a service's PIDFile.
>
On Fri, 19 Feb 2021, Lennart Poettering wrote:
> On Fr, 19.02.21 18:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering
> > wrote:
> >
> > > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> > >
> > > > i guess i
On Fr, 19.02.21 16:29, Ed Greshko (ed.gres...@greshko.com) wrote:
> Link 2 (enp1s0)
> Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
> DefaultRoute setting: yes
> LLMNR setting: yes
> MulticastDNS setting: no
> DNSOverTLS setting: no
> DNSSEC setting: no
> DNSSEC supported: no
On Fr, 19.02.21 18:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
> On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering
> wrote:
>
> > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > > i guess i expected that the CVE identifier would be in the commit
> > > message.
On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering
wrote:
> On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
>
> > i guess i expected that the CVE identifier would be in the commit
> > message. anyway, time to examine ...
>
> CVEs are assigned/published long after the
On Fri, 19 Feb 2021, Lennart Poettering wrote:
> On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
>
> > i guess i expected that the CVE identifier would be in the commit
> > message. anyway, time to examine ...
>
> CVEs are assigned/published long after the commits to fix
On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> i guess i expected that the CVE identifier would be in the commit
> message. anyway, time to examine ...
CVEs are assigned/published long after the commits to fix the issues
are made. We cannot retroactively change git
On Fr, 19.02.21 08:44, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering schrieb am 18.02.2021 um 19:30
> in
> Nachricht :
> ...
> > entry instead of asking for new memory again. This allocation cache is
> > a bit quicker then going to malloc() all the time, but
On Fr, 19.02.21 15:12, Frank Thommen (systemd-de...@lists.drosera.ch) wrote:
> Dear all,
>
> I am experiencing the issue, that an unprivileged user can kill
> root-owned processes by changing a service's PIDFile.
The file referenced by PIDFile= should not be under control of an
unpriv user.
Dear all,
I am experiencing the issue, that an unprivileged user can kill root-owned
processes by changing a service's PIDFile.
Situation: We are running a web service based on a software which is maintained
by "external" developers. The service is running as an unprivileged user and
the
On Fri, 19 Feb 2021, Reindl Harald wrote:
>
>
> Am 19.02.21 um 11:28 schrieb Robert P. J. Day:
> >I *may* have found the problem ... as one can read here:
> >
> > https://access.redhat.com/solutions/3840481
> >
> > "CVE-2019-3815 systemd: memory leak in journald-server.c introduced by
> > fix
On Fri, 19 Feb 2021, Reindl Harald wrote:
>
>
> Am 19.02.21 um 11:28 schrieb Robert P. J. Day:
> >I *may* have found the problem ... as one can read here:
> >
> > https://access.redhat.com/solutions/3840481
> >
> > "CVE-2019-3815 systemd: memory leak in journald-server.c introduced by
> > fix
Am 19.02.21 um 11:28 schrieb Robert P. J. Day:
I *may* have found the problem ... as one can read here:
https://access.redhat.com/solutions/3840481
"CVE-2019-3815 systemd: memory leak in journald-server.c introduced by
fix for CVE-2018-16864"
So as I interpret that, a memory leak
On Thu, 18 Feb 2021, Lennart Poettering wrote:
> On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
>
> > A colleague has reported the following apparent issue in a fairly
> > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > Linux 9 build, hence the
On Thu, 18 Feb 2021, Lennart Poettering wrote:
> On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
>
> > A colleague has reported the following apparent issue in a fairly
> > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > Linux 9 build, hence the
First a little background. I'm using a Fedora 33 system in a qemu VM. I was
doing some research
on a question which arose on a Fedora mailing list regarding changes to
FallbackDNS. I don't know
if this change was universal or Fedora only. But a recent update changed the
default to have no
>>> Reindl Harald schrieb am 19.02.2021 um 09:13 in
Nachricht <068b561d-677f-1abf-ef9f-0f43571e1...@thelounge.net>:
>
> Am 19.02.21 um 08:44 schrieb Ulrich Windl:
> Lennart Poettering schrieb am 18.02.2021 um 19:30
>> in
>> Nachricht :
>> ...
>>> entry instead of asking for new memory
Am 19.02.21 um 08:44 schrieb Ulrich Windl:
Lennart Poettering schrieb am 18.02.2021 um 19:30
in
Nachricht :
...
entry instead of asking for new memory again. This allocation cache is
a bit quicker then going to malloc() all the time, but means if you
just watch the heap you'll assume
22 matches
Mail list logo
