Le Mon, May 06, 2024 at 11:15:35AM +0100, Barak A. Pearlmutter a écrit :
> > We have two separate issues here:
>
> > a/ /tmp-on-tmpfs
Note that /tmp-on-tmpfs and cleanup-tmp-at-boot are not equivalent.
With cleanup-tmp-at-boot, if your system crashes, you can still backup
/tmp before
On Tue, May 07, 2024 at 09:49:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Andrey Rakhmatullin (2024-05-06 19:14:40)
> > On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> > >
> > >
Quoting Andrey Rakhmatullin (2024-05-06 19:14:40)
> On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> >
> > It's a question of what the *default* behaviour should be.
> >
> > For whatever reason, a
I guess sometimes when people discuss technical matters, good ideas pop up.
(Although I still think that its problematic interactions with lengthy
suspends makes the whole idea of auto-deletion based purely on
timestamps problematic. I can imagine more coherent mechanisms, which
doesn't count
Barak A. Pearlmutter wrote:
> You know, that's a pretty good idea!
>
> Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the
> default deletion policy, the policy in place if it's not the default,
> and a pointer to info about altering it. "/tmp's contents are deleted
> at boot
On Tue, 7 May 2024 at 15:53, Sam Hartman wrote:
>
> > "Johannes" == Johannes Schauer Marin Rodrigues
> > writes:
> >> > > If [files can be deleted automatically while mmdebstrap is using
> them],
> >> > > how should applications guard against that from
> >> > > happening?
>
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
>> > > If [files can be deleted automatically while mmdebstrap is using
them],
>> > > how should applications guard against that from
>> > > happening?
>> >
>> > As documented in tmpfiles.d(5), if mmdebstrap takes
> ...3) I would put a file in any auto-cleaned space named "1-AUTOCLEAN.txt"
> that contains some verbage explaining that things in this directory will be
> wiped based on rules set in (wherever).
You know, that's a pretty good idea!
Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly
Maybe putting the cleanup task for /var/tmp on a longer timer and
warning users ahead of time of impending deletion (maybe 3 days before,
2 days, etc) would help with files of unsuspecting users getting
deleted. A log entry could also be emitted. I could see a gentle
warning on ssh login (minimal,
obile device.
From: "Barak A. Pearlmutter"
Sent: Tuesday, May 7, 2024 07:18
To: r...@neoquasar.org
Cc: Luca Boccassi; debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d no
On Tue, 07 May 2024 at 07:34:54 -0500, r...@neoquasar.org wrote:
> possibly convince those applications to use their own
> scratch space such as /tmp// that is more easily identifiable
This would be a denial of service at best, and a privilege escalation
vulnerability at worst. To be safe, it
This, in my opinion, is the correct view.
If the users/admins of a system are putting files somewhere, those are their
files and therefore their responsibility. It is not up to anyone else to claim
they know better and clean up after them.
If the files are abandoned by applications that
Rhys, I think you're being unfair. We have a *technical* disagreement
here. But our hearts are all in the same place: Luca, myself, and all
the other DDs discussing this, all want what's best for our users, we
all want to build the best OS possible, and are all discussing the
issue in good faith.
Luca Boccassi writes:
> On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter wrote:
>>
>> > We have two separate issues here:
>>
>> > a/ /tmp-on-tmpfs
>> > b/ time based clean-up of /tmp and /var/tmp
>>
>> > I think it makes sense to discuss/handle those separately.
>>
>> Agreed.
>>
>> I also
.
From: Luca Boccassi
Sent: Monday, May 6, 2024 08:20
To: Barak A. Pearlmutter
Cc: debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6
Hi,
Quoting Luca Boccassi (2024-05-07 00:09:51)
> To be more specific, as per documentation:
>
> https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html
>
> 'x' lines can be used to override cleanup rules, and support globbing,
> so something like:
>
> x /tmp/mmdebstrap.*
On Mon, 6 May 2024 at 23:00, Johannes Schauer Marin Rodrigues
wrote:
>
> Quoting Luca Boccassi (2024-05-06 23:28:59)
> > On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
> > >
> > > On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues
> > > wrote:
> > > > If [files can be
Quoting Luca Boccassi (2024-05-06 23:28:59)
> On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
> >
> > On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues
> > wrote:
> > > If [files can be deleted automatically while mmdebstrap is using them],
> > > how should applications
On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
>
> On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> > If [files can be deleted automatically while mmdebstrap is using them],
> > how should applications guard against that from
> > happening?
>
> As documented in
On Mon, 6 May 2024 at 21:08, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-05-06 15:20:08)
> > While personal anecdotes and stories can be interesting and amusing in many
> > circumstances, I am not really looking for those at this very moment. What I
> > am
On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> If [files can be deleted automatically while mmdebstrap is using them],
> how should applications guard against that from
> happening?
As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
flock(2)
Hi,
Quoting Luca Boccassi (2024-05-06 15:20:08)
> While personal anecdotes and stories can be interesting and amusing in many
> circumstances, I am not really looking for those at this very moment. What I
> am looking for right now is packages or internal infrastructure that need an
> update to
On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
>
> It's a question of what the *default* behaviour should be.
>
> For whatever reason, a lot of people who process large data use
> /var/tmp/FOO/ as a
On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter wrote:
>
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
>
> It's a question of what the *default* behaviour should be.
No, it is not, at least not for the strawman you conjured. So I gather
that git doesn't warn when
> tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
It's a question of what the *default* behaviour should be.
For whatever reason, a lot of people who process large data use
/var/tmp/FOO/ as a place to store information that should not be
backed up, but also should not just
On Mon, 6 May 2024 at 16:03, Barak A. Pearlmutter wrote:
>
> If it clones into /tmp the *entire* tree will either be reaped (upon
> reboot) or not.
>
> But having just some files deleted from a git dir or git working dir
> is much more dangerous, because various git commands can treat files
>
If it clones into /tmp the *entire* tree will either be reaped (upon
reboot) or not.
But having just some files deleted from a git dir or git working dir
is much more dangerous, because various git commands can treat files
deleted from the working tree as deliberate changes to be committed,
and
On Mon, 6 May 2024 at 15:31, Barak A. Pearlmutter wrote:
>
> > What I am looking for right now is packages or internal
> > infrastructure that need
> > an update to cope with these two changes before I upload them, so if
> > you know of any please do let me know and I'll happily look into it
> >
> What I am looking for right now is packages or internal
> infrastructure that need
> an update to cope with these two changes before I upload them, so if
> you know of any please do let me know and I'll happily look into it
> and at least file a bug, if not a MR. Thanks.
Okay.
git and other
On Mon, 06 May 2024 at 13:41:58 +0100, Barak A. Pearlmutter wrote:
> As someone who regularly deals with large datasets, and keeps them in
> the "approved" don't-back-these-up location /var/tmp
Independent of whether we make the change Luca is suggesting or not,
I don't think /var/tmp is a good
On Mon, 6 May 2024 at 13:42, Barak A. Pearlmutter wrote:
>
> > Then upon reading the release notes, on such a machine, one can simply do:
> >
> > touch /etc/tmpfiles.d/tmp.conf
> >
> > And they get no automated cleanups.
>
> This also disables on-boot cleaning of /tmp/.
Yes, as it's going to be
> Then upon reading the release notes, on such a machine, one can simply do:
>
> touch /etc/tmpfiles.d/tmp.conf
>
> And they get no automated cleanups.
This also disables on-boot cleaning of /tmp/.
The root issue here is that deleting not-read-in-a-while
On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter wrote:
>
> > We have two separate issues here:
>
> > a/ /tmp-on-tmpfs
> > b/ time based clean-up of /tmp and /var/tmp
>
> > I think it makes sense to discuss/handle those separately.
>
> Agreed.
>
> I also don't see any issue with a/, at worst
Barak A. Pearlmutter, le lun. 06 mai 2024 11:15:35 +0100, a ecrit:
> To me, the purpose of /var/tmp/ when I have my "user" hat on is: a
> place to put files I don't want backed up, particularly large ones,
> and which if I run out of disk space is a place to look for stuff to
> delete. it's not "a
> We have two separate issues here:
> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp
> I think it makes sense to discuss/handle those separately.
Agreed.
I also don't see any issue with a/, at worst people will be annoyed
with it for some reason and can then change it back.
>
35 matches
Mail list logo
