Re: [sabayon] Home dir of sabayon

[Daniel Veillard <veillard redhat com>]

On Wed, Mar 02, 2005 at 04:36:32PM +0000, Mark McLoughlin wrote:
> On Wed, 2005-03-02 at 07:40 -0500, Daniel Veillard wrote:
> >   I just checked out the CVs version of sabayon. I notice that
> > its home dir has been removed, and that apparently the code expects to
> > build it on the fly. However this seems to just not work for me. Gconf
> > yells at the result and fills up the syslog with:
> > 
> > Mar  2 13:27:08 paphio gconfd (sabayon-15972): starting (version 2.8.1), pid 15972 user 'sabayon' 
> > Mar  2 13:27:08 paphio gconfd (sabayon-15972): Owner of /tmp/orbit-sabayon is not the current user  
> 
> 	This is the real problem, not the GConf warnings. Its probably that the
> sabayon UID got changed. I thought I'd fixed that, though, by making
> sure the sabayon user isn't removed and re-added during upgrade.

  It think I tried to rpm -U the new package but had to rpm -e / rpm -i 
instead, I don't remember why.

> 	(And yeah, its a bad bug that GConf barfs like this. There's an
> unfinished patch in bugzilla for it.)

  okay, since ~sabayon is being recreated from scratch, shouldn't 
/tmp/orbit-sabayon be destroyed too ? I feel there is a security risk.
  Fixing /tmp/orbit-sabayon, I still get a dozen gconfd warnings in syslog,
like:

Mar  2 18:31:04 paphio gconfd (sabayon-1150): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0 
Mar  2 18:31:04 paphio gconfd (sabayon-1150): Resolved address "xml:readonly:/tmp/sabayon-temp-home-Sg7543/.gconf.xml.mandatory" to a read-only configuration source at position 1 
Mar  2 18:31:04 paphio gconfd (sabayon-1150): Resolved address "xml:readwrite:/tmp/sabayon-temp-home-Sg7543/.gconf" to a writable configuration source at position 2 
Mar  2 18:31:04 paphio gconfd (sabayon-1150): Resolved address "xml:readonly:/tmp/sabayon-temp-home-Sg7543/.gconf.xml.defaults" to a read-only configuration source at position 3 
Mar  2 18:31:04 paphio gconfd (sabayon-1150): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 4 

  maybe GConf2-2.8.1-2 is a bit old.

> >   I wonder why the static home path was changed why there was no discussion
> > about it on the list and the ISSUE file still list this this as an unresolved
> > matter. I think that applications may record home path and do not expect them
> > to change from one launch to another. I think this change fragilize the 
> > ability to actually record application preferences, it makes writing special
> > handlers for configuration files harder and is not justified (it may look
> > more secure but I'm not convinced it actually is since the general Unix login
> > protection mechanism should applies to sabayon).
> 
> 	I thought it was the idea of creating the sabayon user on the fly that
> really worried you rather than creating the homedir?

   Yes, but the homedir path is likely to be part of the configuration.
And unless we have templating rules able to extract the home dir and replace
it with some kind of $HOME generic string I feel some mess going on.

> 	So, the reasons I changed it to this way was:
> 
>   + We need to start with a fresh clean homedir each time
>   + We could just delete everything in /var/sabayon each time, but I'd
>     be worried that people might put stuff in there not expecting it
>     to be deleted
>   + it re-enforces the notion that the sabayon user isn't a real user
> 
> 	And, as for the "apps might save the homedir path in prefs" problem ...
> we need to tackle that anyway. Even if the homedir is /var/sabayon and
> some app does something silly like
> saving /var/sabayon/.gnome/panel2.d/launchers/foo.desktop in its
> preferences, then we're going to need to fix the path anyway whenever we
> apply the profile to a real user.

  yes, agreed ! It should be cleaner, but I'm wondering about side effects.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/