x11 /tmp preparation rc.d script

[Jose M Rodriguez]

Dejan Lesjak escribió:

>[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.
>
The only I know is that this breaks rcNG writing rules.  This is a 
little more than style.  I think that goin more modular can't hurt.

>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?
>  
>
Even more critical paths in the boot process are controlled in this 
manner. Why not?

>Yes of course that would only solve things on -current and -stable, however 
>  
>
This was allways the main problem of solve this 'only base'.

>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).
>  
>
There are PRs on this.  I think that latest rcNG script (with perhaps 
some tweaks to work from ports) installed from Xorg libraries will be 
the better first step.  We may make this install_script conditional when 
we have the problem solved in RELENG_5 base (test OS_VERSION) and lost 
this when RELENG_4 life cycle was expired.

>Dejan
>
>
>  
>
--
  josemi