On Tue, 15 Jan 2008, Tom Lane wrote:
I think on most systems you'd have to explicitly tweak the /tmp-cleaning script to know not to zap such a link. Given that such a local customization would probably disappear in your next system update, the security gain might be fleeting.
Right, on the RedHat box I have handy you'd have to edit /etc/cron.daily/tmpwatch and add "-x s.PGSQL.5432" to the first line there. I don't think that file changes very often because of routine updates anyway, and even if it did you wouldn't lose your custom version. That's listed as a config file, not a binary, so the revised one would show up as tmpwatch.rpmnew and it would be your job to reconcile the packager's changes. People who just let the GUI updater loose might not notice that though.
Other types of systems will obviously have their own ways to cope with such local customization. In the short-term, you're already exposed to the problem when walking down this road because of the edit to the startup script that creates the symlink in the first place. For some people that's also a tweak to a script that could be updated in a conflicting way.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
