[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

x11 /tmp preparation rc.d script



[rc@ list CCed as this threads on their territory, the start of thread is 
here: 
http://lists.freebsd.org/pipermail/freebsd-x11/2005-January/001474.html]

On Monday 10 of January 2005 19:35, Eric Anholt wrote:
> On Mon, 2005-01-10 at 09:40 +0100, Jose M Rodriguez wrote:
> > Jose M Rodriguez escribi?:
> > > Eric Anholt escribi?:
> > >> Attached are my proposed patches to deal with the X11 ICE issue.  To
> > >> review, it's required because having .ICE not owned by root is a
> > >> security issue, one that's been papered over with a printed warning
> > >> and sleep(5) in libICE for years, and has recently been changed into
> > >> an actual error by the X.Org folks.
> >
> > ...
> >
> > As a latter think about this, consider take also periodic related fixes
> > (We clear this directories by default) and try to get a OS_VERSION bump
> > closest to this.
>
> I'm sorry, I'm not sure what exactly you're talking about here.  Are you
> saying that /etc/periodic contains something that will wipe out X's
> files in /tmp?  That would be rather broken.

/etc/periodic/daily/110.clean-tmps cleans out empty directories that have not 
been modified in $daily_clean_tmps_days days. This ones should therefore be 
added to $daily_clean_tmps_ignore in /etc/defaults/periodic.conf, just to be 
on the safe side.

Other than that, I don't really know what would be the best way to handle 
creation of this directories and haven't commented so far, but since I'm 
already writing (mostly because I thought rc@ list should be CCed), here's my 
opinion FWIW: the simplest seems to be a patch from Pawel Worach at 
http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/042445.html
The benefit of using this simple approach is that it is simple (of course :) 
and furthermore it only adds two more directories to /tmp at startup as 
oposed to adding a file in /etc/rc.d. The difference being one inode. But 
then again, perhaps I don't see all the implications and this is too simple. 
Is there a real benefit in creating another rc.d script for doing this and 
adding a knob to turn creation of these directories off?
Yes of course that would only solve things on -current and -stable, however 
there is already an UPDATING entry for this and we can always add a script to 
be installed from a port that would take care of transition period (probably 
as soon in dependency tree as possible, ie -libraries).

Dejan

Visit your host, monkey.org