Re: F20 System Wide Change: Web Assets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux