Permissions on key directories/files.

[Jim Gettys]

The situation is a bit more subtle.

Some people mount memory file systems on /tmp; so you can't
rely on installation to get the ownership right. So /tmp
is fundamentally different than /lib or /usr/lib, etc.

The other issue is that we don't normally seem to be emitting
the error message in circumstances that people actually see it;
so failing hard without saying why in a visible way is a problem.

Certainly, either: 1) having {x,g,k}dm set up the directories is
one fix, 2) a helper program is another, and there may be others
I haven't thought about.  But saying the installation process
should fix it isn't a robust fix.
                              - Jim

On Sat, 2004-03-20 at 18:26, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat March 20 2004 02:02, George wrote:
> > On Tue, Mar 16, 2004 at 05:20:36PM +0100, Egbert Eich wrote:
> > > If the sticky bit is not set or the ownership of this directory
> > > is not root we risk a man-in-the-middle attack. Even if the sticky bit
> > > is set the owner of the directory is able to do the attack.
> > > Therefore the function that attempts to create these directories
> > > (if they don't exist) should fail hard and print a meaningful
> > > error message.
> > > It should be the responsibility of the install procedure and/or
> > > the OS vendor to make sure that these directories exist and have the
> > > correct ownership and permissions.
> > > Letting x,g,kdm or whatever create these directories is just a
> > > convenience fix for people who have a habit to delete those directories.
> >
> > Some cleanup tasks might whack those directories.  I think it's robustness
> > issue.  Yes it should be handled by the install, but better handle this at
> > multiple places to truly ENSURE that it's ok.  gdm currently does the
> > /tmp/.ICE-unix dance but not the /tmp/.X11-unix dance, it should perhaps do
> > that as well, though I was always sort of expecting the X server to run as
> > root and set this up, but I suppose that's not a correct assumption.  Plus
> > we should never expect that things will be just set up properly.  For
> > example a hard drive failure or some crazy setup might whack the initial
> > /tmp settings, we shouldn't fail to be secure in those instances.
> 
> failing hard and printing a meaningful error message is secure IMHO.
> 
> As far as the robustness goes, if you delete or corrupt random files out 
> of /lib your system will not work either, get over it.
> 
> Cheers,
> Waldo
> - -- 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> ^ bastian at kde.org | Is your software SUSE LINUX READY? | bastian at suse.com
> ^<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQFAXNMvN4pvrENfboIRApcTAJ9i1YeYC8ZtFrmSapnrDXL9Tcbi/ACdFtnG
> Xnu0RDpoZsnY4reIlH4ZM6M=
> =7DOG
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
-- 
Jim Gettys <Jim.Gettys at hp.com>
HP Labs, Cambridge Research Laboratory