On Thu, Aug 8, 2013 at 11:45 AM, Robert Marcano <rob...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
