** Changed in: systemd (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2088268
Title:
systemd /tmp cleaning removes files that it shouldn't
To manage noti
So, before systemd-tmpfiles was used, Ubuntu used tmpreaper to perform
periodic cleaning of the /tmp dir. tmpreaper had a list of exceptions:
--protect '/tmp/.X*-{lock,unix,unix/*}' \
--protect '/tmp/.ICE-{unix,unix/*}' \
--protect '/tmp/.iroha_{unix,unix/*}' \
--protect '/tmp/.ki2-{unix,unix/*}'
What @bluca says is mostly true and valid. But it is how things should
be, not how things actually are, and getting from the latter to the
former is easier said than done. E.g. with Xorg it *might* be
straightforward to fix the server and simple clients (i.e. those that
just call XOpenDisplay). But
It is also too aggressively clearing files and sub-folders under
~/.cache/. For instance, on my instances of 24.04.1, I am consistently
losing ibus communication because the contents of the ~/.cache folder is
being wiped too aggressively by the systemd-tmpfiles-clean.service.
--
You received this
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: xorg (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2088268
Title:
syste
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2088268
Title:
sy
/tmp/ is world writable, so there is no guarantee that one process will
be the first to write to a file anyway. The case of "another process
replaced it after deletion" is the same as "another process got there
first on boot", and cannot be avoided. Anything using /tmp/ needs to be
aware of this, a
I went through this - as my first thought this looks perfectly
plausible. I'll try to repro this and create a PoC for the usecase
mentioned here.
I'll additionally like people from bug #2019026 to weigh in as well
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Assigning ~ubuntu-security to get an opinion about this topic.
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
** Tags added: rls-nn-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2088268
Title:
systemd /tmp cleaning removes files that it shouldn't
To manage notifications about this bug go to:
https
Sure, I can fix it in my systems, and have done so. But other users
using the default settings will still have a potential security
vulnerability in their systems.
And the X11 files is a case we know about; there might be other programs
using /tmp in a similar way (such as the TigerVNC case), and
As mentioned on bug 2088433, you can create a local override if you want
something different than the default. E.g. create
/etc/tmpfiles.d/tmp.conf with your own configuration for /tmp.
Regarding x11.conf, this has been that way for a long time AFAICT, and I
don't know enough about that package to
Also, full disclosure: I have the noatime mount option set for the root
filesystem, which certainly exacerbates the problem, e.g. the TigerVNC
issue would have been less likely (instead of certain) without noatime.
But noatime is not the cause of the problem: all the bad scenarios
listed are perfec
Now that I have had more time to ponder this issue, I realize that it is
also a security vulnerability. And spurred by the realization, I vaguely
recall coming across several articles in the past (some from before
systemd was a thing) about how automatic runtime cleaning of /tmp and
/var/tmp is (or
14 matches
Mail list logo
