On Thu, Aug 8, 2013 at 11:45 AM, Robert Marcano
<robert(a)marcanoonline.com> wrote:
And I don't see a problems with those examples, because they
share only
their contents, by installing them you don't share content from other
packages.
Lets make an example of the mess this will create if I want to share a web
application to the world and user another one on my intranet. I will call
those Internet and Intranet application
Internet application requires JavaScript library intranet-library, and the
same with intranet-library.
Both applications are installed, I as a sysadmin don't want to expose
intranet used assets to the general public, so I need to make changes on
it's respective apache configuration file in order to explicitly block
/usr/share/web-assets/javascript/intranet-library.
A new update to intranet application adds a new requirement.
new-intranet-library. So I as a sysadmin must be checking every package
installed in order to see if it is exposing more things to the public. You
can have many reasons for not wanting that, license of those files, avoid
people linking to them and use your bandwidth.
The shared directory thing makes this easier! Instead of having to
track down which application aliases which library in which apache
config fragment, you just have one directory to check. (Not to
mention you'll plainly see in yum's output when this happens, anyway.)
You can also whitelist/blacklist/use a different version of individual
libraries centrally, even per VirtualHost, instead of tracking down a
million aliases.
I am not against creating some order and removing the privilege that
JavaScript code and assets currently have of being allowed to be bundled on
every package. But sharing /usr/share/fonts and /usr/share/javascript by
default is bad.
I think web applications should link themselves to each asset they need on
its directory/namespace. You will probably loose the advantage of having
only one URL for the same file if you install multiple web applications, but
you gain more control having each application using one directory/namespace
and only one
SELinux must be taken into consideration too, be it that those directories
get finally shared entirely or not. Will be created a new SELinux context
for font (already exist), JavasScript code and other files?, in order to
allow Apache to read files outside /var/www. With the current way of
packaging of bundling everything this wasn't a problem because files were
part of the application, not anymore with these proposal
SELinux currently doesn't prevent any of the accesses we need. There
might be a couple opportunities to actually lock down stuff more
thanks to the improvements here, but that's just gravy.
-T.C.