XDG and default directories (Re: Adding ~/.local/bin to default PATH)

Stijn Hoop stijn at sandcat.nl
Wed Jul 27 14:52:05 UTC 2011


Hi,

On Wed, 27 Jul 2011 12:43:09 +0200
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> Le mercredi 27 juillet 2011 à 12:26 +0200, Stijn Hoop a écrit :
> >  and even better is the fact that I can now put that area
> > somewhere else than on our default stupidly-expensive backupped NFS
> > filesystem.
> 
> And what will happen to your users when selinux starts enforcing
> download jails and the directory it applies settings to is not the one
> you use? Do you really thinks that's hypothetical? Browsers are
> looking hard at sandboxing nowadays. Note that other security
> frameworks do not even have the path/label separation they work
> directly on paths.

Why would selinux / apparmor NOT respect the same environment that is
used for the live user?

If the root cause is because selinux / apparmor is technically not able
to use per-user environment variables for non-standard subdirectories
of /home, I submit that I simply need to be capable to not only set the
environment variable, but also modify our selinux configuration to
match.

I already accepted the premise that having an NFS mounted /home (where
I preferably do not want to store the newest HQ movies) is not a
standard Linux environment anymore, by having to set the variable in
the first place.

> Really if there was a need (for nfs users for example) for the
> download area to reside on a different root it should have been
> defined on a different root from the start up (like the rest of the
> filesystem layout was done) instead of trying to variabilize the
> layout.

I agree, that would also work in this specific case. However I note
that the defaults make sense in a personal workstation case, which is
fine by me. Having /home and /localhome (examples) for a single
workstation is more confusing.

> Now the default locations are just going to be hardcoded
> right and left with subtle difficult to debug failures when one tries
> to move one of them like proposed by the spec.

Exactly my point as well, let's get those fixed.

--Stijn


More information about the devel mailing list