Re: Include /var/www/tmp into base install
On Wed, Apr 08, 2020 at 11:08:41AM +0100, Kevin Chadwick wrote: > On 2020-04-07 17:12, Andrew Grillet wrote: > > For me, the "/var is full" problem can be adequately mitigated by mounting > > a separate partition as /var/tmp. > > Does FFS2 have the same disklabel limit on partitions? I guess they are > unrelated. Unrelated. > > Sometimes users may decide which mount points to edit out during install and > /var/tmp gives one more for them to understand if it's a problem moving to > /var. > > Creating /var/tmp is actually a simpler consideration than removing an OS > provided /var/tmp > > On web servers, I have /var/www and /var/www/bin as well as others on mount > points so e.g. /var/www is noexec and optionally read-only. /var/www/tmp is > sometimes mfs. > > That many mount points obviously doesn't fit so well generically but > permissive > permissions if more mount points were available, might work. > > I also wonder why /var/log is not on it's own partition by default. I almost > always create it. I guess for smaller disks, more mount points is a pain? > > > > More of an issue, although obviously not major - if there are a large > > number of tmp directories, is making sure that they are all > > routinely purged. Yes, I know this is down to careless admin practice, but > > it happened to me earlier this year. > > A smaller partition would actually have less inodes by default ffs settings. > Something to consider. No idea if/how ffs2 changes that? With default parameter an FFS2 fuilesystem will have almost the same number of inodes as an FFS1 filesystem. Note that disklabel instructs newfs (via the fsize/bsize fields in the label) to use larger block sizes for larger partitions, resulting in less inodes compared to size. But for the same size class it's a linear relation. -Otto
Re: Include /var/www/tmp into base install
On 2020-04-07 17:12, Andrew Grillet wrote: > For me, the "/var is full" problem can be adequately mitigated by mounting > a separate partition as /var/tmp. Does FFS2 have the same disklabel limit on partitions? I guess they are unrelated. Sometimes users may decide which mount points to edit out during install and /var/tmp gives one more for them to understand if it's a problem moving to /var. Creating /var/tmp is actually a simpler consideration than removing an OS provided /var/tmp On web servers, I have /var/www and /var/www/bin as well as others on mount points so e.g. /var/www is noexec and optionally read-only. /var/www/tmp is sometimes mfs. That many mount points obviously doesn't fit so well generically but permissive permissions if more mount points were available, might work. I also wonder why /var/log is not on it's own partition by default. I almost always create it. I guess for smaller disks, more mount points is a pain? > More of an issue, although obviously not major - if there are a large > number of tmp directories, is making sure that they are all > routinely purged. Yes, I know this is down to careless admin practice, but > it happened to me earlier this year. A smaller partition would actually have less inodes by default ffs settings. Something to consider. No idea if/how ffs2 changes that?
Re: Include /var/www/tmp into base install
On 4/7/20 6:05 PM, Stuart Henderson wrote: fwiw my usual approach is to put /var/www on a separate filesystem .. I do generally create a separate filesystem for /var/www/tmp (and /var/www). But I feel this is the responsibility of whoever installs stuff which will write in this directory to adapt the filesystem to whatever parameters he will need. The base OS doesn't need it at all. We cannot predict what one needs for capacity will be. This would also be valid for /var/mail, one can fill it with mails for root from cron. smime.p7s Description: S/MIME Cryptographic Signature
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 06:13:12PM +0200, Stefan Sperling wrote: > For temp stuff we really need a separate space that can just be wiped > without consequences when it has run full. The way Got internally provides access to files in /tmp for every helper process is to pass one or more open file descriptors for files in /tmp from the main process to the helper process. The helper doesn't have any direct filesystem access. Of course it could fill up /tmp with this one file, but not /var. It would be nice if e.g. slowcgi could provide something like that. At present gotweb uses /var/www/got/tmp instead of /tmp because its main process runs in /var/www chroot via slowcgi.
Re: Include /var/www/tmp into base install
For me, the "/var is full" problem can be adequately mitigated by mounting a separate partition as /var/tmp. More of an issue, although obviously not major - if there are a large number of tmp directories, is making sure that they are all routinely purged. Yes, I know this is down to careless admin practice, but it happened to me earlier this year. I can't give them all their own partitions. On Tue, 7 Apr 2020 at 16:58, Theo de Raadt wrote: > Stefan Sperling wrote: > > > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > > > The idea was to have /var/www/tmp created by default, but with > > > > www:www ownership. > > > > > Create the directory. Now as a user, completely fill it. > > > > The proposal is to create tmp with www:www ownership, writable only for > > that user, not like the old /var/tmp which was writable by anyone. > > That's not true; the diff created it mode 1777. > > A smaller secondary concern is if you can convince software using this > space, > from remote, to hog the space too much, and/or lose track of files in > there. > Which would also create the fallout problems of "/var is full". > > It's a matter of how other /var-using software misbehaves or fails in > those circumstances. These concerns have been ignored too long. > >
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 05:05:08PM +0100, Stuart Henderson wrote: > On 2020/04/07 18:01, Stefan Sperling wrote: > > Yes, absolutely correct. Logs or tempfiles filling up /var are a problem, > > and in the gotweb application Tracey and I created it is indeed possible > > for requests to trigger large tempfiles. We need to look at that and come > > up with a better solution. > > We could check whether httpd/slowcgi could help with this somehow and try > > to come up with something that works for any application and not just ours. > > > > fwiw my usual approach is to put /var/www on a separate filesystem .. I had that in mind, too. But then you can still fill up that partition, and in gotweb's case it has Git repositories which also freak out in various ways if you run them out of disk. So it doesn't solve the problem from the application's point of view. Like regular /var, these repositories always need some breathing room. For temp stuff we really need a separate space that can just be wiped without consequences when it has run full.
Re: Include /var/www/tmp into base install
Stuart Henderson wrote: > On 2020/04/07 18:01, Stefan Sperling wrote: > > On Tue, Apr 07, 2020 at 09:51:15AM -0600, Theo de Raadt wrote: > > > Stefan Sperling wrote: > > > > > > > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > > > > > The idea was to have /var/www/tmp created by default, but with > > > > > > www:www ownership. > > > > > > > > > Create the directory. Now as a user, completely fill it. > > > > > > > > The proposal is to create tmp with www:www ownership, writable only for > > > > that user, not like the old /var/tmp which was writable by anyone. > > > > > > That's not true; the diff created it mode 1777. > > > > Ah, I missed that. Yes that would be a problem in the diff. > > > > > A smaller secondary concern is if you can convince software using this > > > space, > > > from remote, to hog the space too much, and/or lose track of files in > > > there. > > > Which would also create the fallout problems of "/var is full". > > > > > > It's a matter of how other /var-using software misbehaves or fails in > > > those circumstances. These concerns have been ignored too long. > > > > Yes, absolutely correct. Logs or tempfiles filling up /var are a problem, > > and in the gotweb application Tracey and I created it is indeed possible > > for requests to trigger large tempfiles. We need to look at that and come > > up with a better solution. > > We could check whether httpd/slowcgi could help with this somehow and try > > to come up with something that works for any application and not just ours. > > > > fwiw my usual approach is to put /var/www on a separate filesystem .. That's my approach also. But now /var/www can get filled. The problem is how will /tmp files be handled? Sloppily, I predict.
Re: Include /var/www/tmp into base install
Stefan Sperling wrote: > > A smaller secondary concern is if you can convince software using this > > space, > > from remote, to hog the space too much, and/or lose track of files in there. > > Which would also create the fallout problems of "/var is full". > > > > It's a matter of how other /var-using software misbehaves or fails in > > those circumstances. These concerns have been ignored too long. > > Yes, absolutely correct. Logs or tempfiles filling up /var are a problem, > and in the gotweb application Tracey and I created it is indeed possible > for requests to trigger large tempfiles. We need to look at that and come > up with a better solution. > We could check whether httpd/slowcgi could help with this somehow and try > to come up with something that works for any application and not just ours. I'm worried anyone using a tmp directory is going to write software which "loses files" when it crashes. That's yet another reason why a filesystem can get full. And when /var gets full, there are big consequences. We've done pretty much NOTHING to the other /var consuming-software to make sure they work (or fail kindly) when /var is full. It is an ignored problem. It only takes a little experiment to know the problem is real.
Re: Include /var/www/tmp into base install
On 2020/04/07 18:01, Stefan Sperling wrote: > On Tue, Apr 07, 2020 at 09:51:15AM -0600, Theo de Raadt wrote: > > Stefan Sperling wrote: > > > > > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > > > > The idea was to have /var/www/tmp created by default, but with > > > > > www:www ownership. > > > > > > > Create the directory. Now as a user, completely fill it. > > > > > > The proposal is to create tmp with www:www ownership, writable only for > > > that user, not like the old /var/tmp which was writable by anyone. > > > > That's not true; the diff created it mode 1777. > > Ah, I missed that. Yes that would be a problem in the diff. > > > A smaller secondary concern is if you can convince software using this > > space, > > from remote, to hog the space too much, and/or lose track of files in there. > > Which would also create the fallout problems of "/var is full". > > > > It's a matter of how other /var-using software misbehaves or fails in > > those circumstances. These concerns have been ignored too long. > > Yes, absolutely correct. Logs or tempfiles filling up /var are a problem, > and in the gotweb application Tracey and I created it is indeed possible > for requests to trigger large tempfiles. We need to look at that and come > up with a better solution. > We could check whether httpd/slowcgi could help with this somehow and try > to come up with something that works for any application and not just ours. > fwiw my usual approach is to put /var/www on a separate filesystem ..
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 09:51:15AM -0600, Theo de Raadt wrote: > Stefan Sperling wrote: > > > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > > > The idea was to have /var/www/tmp created by default, but with > > > > www:www ownership. > > > > > Create the directory. Now as a user, completely fill it. > > > > The proposal is to create tmp with www:www ownership, writable only for > > that user, not like the old /var/tmp which was writable by anyone. > > That's not true; the diff created it mode 1777. Ah, I missed that. Yes that would be a problem in the diff. > A smaller secondary concern is if you can convince software using this space, > from remote, to hog the space too much, and/or lose track of files in there. > Which would also create the fallout problems of "/var is full". > > It's a matter of how other /var-using software misbehaves or fails in > those circumstances. These concerns have been ignored too long. Yes, absolutely correct. Logs or tempfiles filling up /var are a problem, and in the gotweb application Tracey and I created it is indeed possible for requests to trigger large tempfiles. We need to look at that and come up with a better solution. We could check whether httpd/slowcgi could help with this somehow and try to come up with something that works for any application and not just ours.
Re: Include /var/www/tmp into base install
Stefan Sperling wrote: > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > > The idea was to have /var/www/tmp created by default, but with > > > www:www ownership. > > > Create the directory. Now as a user, completely fill it. > > The proposal is to create tmp with www:www ownership, writable only for > that user, not like the old /var/tmp which was writable by anyone. That's not true; the diff created it mode 1777. A smaller secondary concern is if you can convince software using this space, from remote, to hog the space too much, and/or lose track of files in there. Which would also create the fallout problems of "/var is full". It's a matter of how other /var-using software misbehaves or fails in those circumstances. These concerns have been ignored too long.
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote: > > The idea was to have /var/www/tmp created by default, but with > > www:www ownership. > Create the directory. Now as a user, completely fill it. The proposal is to create tmp with www:www ownership, writable only for that user, not like the old /var/tmp which was writable by anyone. Currently ports create per-application temp directories for this purpose when they get installed. I think this is fine and helps to keep unrelated things apart, so I don't see a reason to create a global 'www:www' tmp unless it helps ports sigificantly.
Re: Include /var/www/tmp into base install
Stuart Henderson wrote: > On 2020/04/07 09:01, Theo de Raadt wrote: > > This is horrible, as a user can fill the /var filesystem. > > they already can with /var/www/logs. On my machines not running this software, they cannot cause any effect on that directory. The software utilization of 1% of machines should not create risk on the other 99% of machines. Regardless, we should be moving towards making /var over-utilization safer, rather than less safe.
Re: Include /var/www/tmp into base install
Tracey Emery wrote: > On Tue, Apr 07, 2020 at 11:17:23AM -0400, Bryan Steele wrote: > > On Tue, Apr 07, 2020 at 04:56:31PM +0200, Martijn van Duren wrote: > > > This came up during u2k20 while discussing tempfiles for gotweb inside a > > > chroot. At the moment we don't include it by default and ports have to > > > create it themselves. Since I assume we want web applications to run > > > inside a /var/www chroot as much as possible and even some libc > > > functions depend on /tmp being available I'd argue we should include it > > > by default. > > > > WIth FastCGI, perhaps I'm confused, but why do web applications need to > > be inside the /var/www chroot? Can't they be anywhere, or even have a > > seperate chroot directory? Should we be handling things things that > > are not in base? > > Both slowcgi(8) and httpd(8) chroot to /var/www and are set to the www > user. The idea was to have /var/www/tmp created by default, but with > www:www ownership. This would eliminate multiple ports from creating the > directory and allow daily to clean the dir. > > To Theo's point, how was /var/tmp used in the past that it caused > problems? I'm struggling to find any info in past mailing lists. Please, please, please why don't you try it. Create the directory. Now as a user, completely fill it. Now your /var is full. Just do it, on an actual machine. Actually do it, don't just talk about it. Now be observant and consider the consequences. This isn't rocket science.
Re: Include /var/www/tmp into base install
On 2020/04/07 09:01, Theo de Raadt wrote: > This is horrible, as a user can fill the /var filesystem. they already can with /var/www/logs. On 2020/04/07 11:17, Bryan Steele wrote: > WIth FastCGI, perhaps I'm confused, but why do web applications need to > be inside the /var/www chroot? Can't they be anywhere, or even have a > seperate chroot directory? They can be, but slowcgi defaults are to chroot to /var/www and some cgi programs want access to files withing the web server's chroot directory. > Should we be handling things things that > are not in base? *shrug* > > Index: etc//mtree/4.4BSD.dist > > === > > RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v > > retrieving revision 1.314 > > diff -u -p -r1.314 4.4BSD.dist > > --- etc//mtree/4.4BSD.dist 29 Nov 2019 03:28:20 - 1.314 > > +++ etc//mtree/4.4BSD.dist 7 Apr 2020 14:37:15 - > > @@ -749,6 +749,7 @@ var > > .. > > runtype=dir uname=root gname=daemon > > mode=755 > > .. > > +tmptype=dir uname=root gname=wheel > > mode=01777 > > .. > > > > # ./var/audit > > > > this wasn't tested :)
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 11:17:23AM -0400, Bryan Steele wrote:
> On Tue, Apr 07, 2020 at 04:56:31PM +0200, Martijn van Duren wrote:
> > This came up during u2k20 while discussing tempfiles for gotweb inside a
> > chroot. At the moment we don't include it by default and ports have to
> > create it themselves. Since I assume we want web applications to run
> > inside a /var/www chroot as much as possible and even some libc
> > functions depend on /tmp being available I'd argue we should include it
> > by default.
>
> WIth FastCGI, perhaps I'm confused, but why do web applications need to
> be inside the /var/www chroot? Can't they be anywhere, or even have a
> seperate chroot directory? Should we be handling things things that
> are not in base?
Both slowcgi(8) and httpd(8) chroot to /var/www and are set to the www
user. The idea was to have /var/www/tmp created by default, but with
www:www ownership. This would eliminate multiple ports from creating the
directory and allow daily to clean the dir.
To Theo's point, how was /var/tmp used in the past that it caused
problems? I'm struggling to find any info in past mailing lists.
>
> > I also choose to make the directory 1777, similar to a normal /tmp,
> > since both multiple slowcgi or php-fpm pools can run simultaneously
> > under different users.
> >
> > The cleanup functions don't reflect the current /tmp cleanup style, but
> > we can move the existing find statements to -delete in a separate patch.
> >
> > I already had some positive feedback during u2k20 on the concept.
> > OK?
> >
> > martijn@
> >
> > Index: etc//daily
> > ===
> > RCS file: /cvs/src/etc/daily,v
> > retrieving revision 1.93
> > diff -u -p -r1.93 daily
> > --- etc//daily 9 Sep 2019 20:02:26 - 1.93
> > +++ etc//daily 7 Apr 2020 14:37:15 -
> > @@ -55,6 +55,11 @@ if [ -d /tmp -a ! -L /tmp ]; then
> > ! -path ./.ICE-unix ! -name . \
> > -execdir rmdir -- {} \; >/dev/null 2>&1; }
> > fi
> > +if [ -d /var/www/tmp -a ! -L /var/www/tmp ]; then
> > + cd /var/www/tmp && {
> > + find -x . -type f -atime +7 -delete 2>/dev/null
> > + find -x . -type d -empty -delete 2>/dev/null
> > +fi
> >
> > # Additional junk directory cleanup would go like this:
> > #if [ -d /scratch -a ! -L /scratch ]; then
> > Index: etc//rc
> > ===
> > RCS file: /cvs/src/etc/rc,v
> > retrieving revision 1.543
> > diff -u -p -r1.543 rc
> > --- etc//rc 24 Jan 2020 06:17:37 - 1.543
> > +++ etc//rc 7 Apr 2020 14:37:15 -
> > @@ -532,7 +532,7 @@ if [[ -f /etc/ptmp ]]; then
> > 'password file may be incorrect -- /etc/ptmp exists'
> > fi
> >
> > -echo clearing /tmp
> > +echo clearing temporary directories
> >
> > # Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
> > # (not needed with mfs /tmp, but doesn't hurt there...).
> > @@ -540,6 +540,7 @@ echo clearing /tmp
> > (cd /tmp &&
> > find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
> > ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
> > +(cd /var/www/tmp && find . -x -delete)
> >
> > # Create Unix sockets directories for X if needed and make sure they have
> > # correct permissions.
> > Index: etc//mtree/4.4BSD.dist
> > ===
> > RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> > retrieving revision 1.314
> > diff -u -p -r1.314 4.4BSD.dist
> > --- etc//mtree/4.4BSD.dist 29 Nov 2019 03:28:20 - 1.314
> > +++ etc//mtree/4.4BSD.dist 7 Apr 2020 14:37:15 -
> > @@ -749,6 +749,7 @@ var
> > ..
> > runtype=dir uname=root gname=daemon
> > mode=755
> > ..
> > +tmptype=dir uname=root gname=wheel
> > mode=01777
> > ..
> >
> > # ./var/audit
> >
> >
--
Tracey Emery
Re: Include /var/www/tmp into base install
On Tue, Apr 07, 2020 at 04:56:31PM +0200, Martijn van Duren wrote:
> This came up during u2k20 while discussing tempfiles for gotweb inside a
> chroot. At the moment we don't include it by default and ports have to
> create it themselves. Since I assume we want web applications to run
> inside a /var/www chroot as much as possible and even some libc
> functions depend on /tmp being available I'd argue we should include it
> by default.
WIth FastCGI, perhaps I'm confused, but why do web applications need to
be inside the /var/www chroot? Can't they be anywhere, or even have a
seperate chroot directory? Should we be handling things things that
are not in base?
> I also choose to make the directory 1777, similar to a normal /tmp,
> since both multiple slowcgi or php-fpm pools can run simultaneously
> under different users.
>
> The cleanup functions don't reflect the current /tmp cleanup style, but
> we can move the existing find statements to -delete in a separate patch.
>
> I already had some positive feedback during u2k20 on the concept.
> OK?
>
> martijn@
>
> Index: etc//daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.93
> diff -u -p -r1.93 daily
> --- etc//daily9 Sep 2019 20:02:26 - 1.93
> +++ etc//daily7 Apr 2020 14:37:15 -
> @@ -55,6 +55,11 @@ if [ -d /tmp -a ! -L /tmp ]; then
> ! -path ./.ICE-unix ! -name . \
> -execdir rmdir -- {} \; >/dev/null 2>&1; }
> fi
> +if [ -d /var/www/tmp -a ! -L /var/www/tmp ]; then
> + cd /var/www/tmp && {
> + find -x . -type f -atime +7 -delete 2>/dev/null
> + find -x . -type d -empty -delete 2>/dev/null
> +fi
>
> # Additional junk directory cleanup would go like this:
> #if [ -d /scratch -a ! -L /scratch ]; then
> Index: etc//rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.543
> diff -u -p -r1.543 rc
> --- etc//rc 24 Jan 2020 06:17:37 - 1.543
> +++ etc//rc 7 Apr 2020 14:37:15 -
> @@ -532,7 +532,7 @@ if [[ -f /etc/ptmp ]]; then
> 'password file may be incorrect -- /etc/ptmp exists'
> fi
>
> -echo clearing /tmp
> +echo clearing temporary directories
>
> # Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
> # (not needed with mfs /tmp, but doesn't hurt there...).
> @@ -540,6 +540,7 @@ echo clearing /tmp
> (cd /tmp &&
> find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
> ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
> +(cd /var/www/tmp && find . -x -delete)
>
> # Create Unix sockets directories for X if needed and make sure they have
> # correct permissions.
> Index: etc//mtree/4.4BSD.dist
> ===
> RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> retrieving revision 1.314
> diff -u -p -r1.314 4.4BSD.dist
> --- etc//mtree/4.4BSD.dist29 Nov 2019 03:28:20 - 1.314
> +++ etc//mtree/4.4BSD.dist7 Apr 2020 14:37:15 -
> @@ -749,6 +749,7 @@ var
> ..
> run type=dir uname=root gname=daemon mode=755
> ..
> +tmp type=dir uname=root gname=wheel mode=01777
> ..
>
> # ./var/audit
>
>
Re: Include /var/www/tmp into base install
This is horrible, as a user can fill the /var filesystem.
That is why we got rid of /var/tmp before, and tried to reduce the risk on
/tmp. Now you want to bring the problem back.
Martijn van Duren wrote:
> This came up during u2k20 while discussing tempfiles for gotweb inside a
> chroot. At the moment we don't include it by default and ports have to
> create it themselves. Since I assume we want web applications to run
> inside a /var/www chroot as much as possible and even some libc
> functions depend on /tmp being available I'd argue we should include it
> by default.
>
> I also choose to make the directory 1777, similar to a normal /tmp,
> since both multiple slowcgi or php-fpm pools can run simultaneously
> under different users.
>
> The cleanup functions don't reflect the current /tmp cleanup style, but
> we can move the existing find statements to -delete in a separate patch.
>
> I already had some positive feedback during u2k20 on the concept.
> OK?
>
> martijn@
>
> Index: etc//daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.93
> diff -u -p -r1.93 daily
> --- etc//daily9 Sep 2019 20:02:26 - 1.93
> +++ etc//daily7 Apr 2020 14:37:15 -
> @@ -55,6 +55,11 @@ if [ -d /tmp -a ! -L /tmp ]; then
> ! -path ./.ICE-unix ! -name . \
> -execdir rmdir -- {} \; >/dev/null 2>&1; }
> fi
> +if [ -d /var/www/tmp -a ! -L /var/www/tmp ]; then
> + cd /var/www/tmp && {
> + find -x . -type f -atime +7 -delete 2>/dev/null
> + find -x . -type d -empty -delete 2>/dev/null
> +fi
>
> # Additional junk directory cleanup would go like this:
> #if [ -d /scratch -a ! -L /scratch ]; then
> Index: etc//rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.543
> diff -u -p -r1.543 rc
> --- etc//rc 24 Jan 2020 06:17:37 - 1.543
> +++ etc//rc 7 Apr 2020 14:37:15 -
> @@ -532,7 +532,7 @@ if [[ -f /etc/ptmp ]]; then
> 'password file may be incorrect -- /etc/ptmp exists'
> fi
>
> -echo clearing /tmp
> +echo clearing temporary directories
>
> # Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
> # (not needed with mfs /tmp, but doesn't hurt there...).
> @@ -540,6 +540,7 @@ echo clearing /tmp
> (cd /tmp &&
> find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
> ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
> +(cd /var/www/tmp && find . -x -delete)
>
> # Create Unix sockets directories for X if needed and make sure they have
> # correct permissions.
> Index: etc//mtree/4.4BSD.dist
> ===
> RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> retrieving revision 1.314
> diff -u -p -r1.314 4.4BSD.dist
> --- etc//mtree/4.4BSD.dist29 Nov 2019 03:28:20 - 1.314
> +++ etc//mtree/4.4BSD.dist7 Apr 2020 14:37:15 -
> @@ -749,6 +749,7 @@ var
> ..
> run type=dir uname=root gname=daemon mode=755
> ..
> +tmp type=dir uname=root gname=wheel mode=01777
> ..
>
> # ./var/audit
>
