It looks like less-rails uses v8 library to do some JavaScript
compilation. Ppl with experiences with SCL building know this library
very well
Couple of questions:
what do we use less-rails for?
do we need to use it during runtime?
It looks like not allowing the EXECMEM does not hurt Foreman w/ Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule upstream
yesterday but I am going to revert that.
> Hello,
>
> last couple of days, I was chasing down the EXECMEM denial which seems
> to be quite dangerous to allow for the Passenger process.
>
> With great help of Ivan, we were able to identify that it's less-rails
> dependency that has this kind of behaviour (or faulty code).
>
> https://github.com/Katello/katello/blob/master/engines/bastion/lib/bastion.rb#L2
>
> It looks like less-rails uses v8 library to do some JavaScript
> compilation. Ppl with experiences with SCL building know this library
> very well
>
> Couple of questions:
>
> - what do we use less-rails for?
The Bastion engine uses LESS as it's stylesheet language along with
some of the third party (e.g. patternfly) CSS libraries. The
stylesheets are compiled at build time no different than other assets.
> - do we need to use it during runtime?
No. However, if we want to support asset regeneration then it will
need to exist.
My questions:
What is less-rails doing specifically that causes this issue?
Why don't we see similar issues given that our JS is compiled through V8?
Wouldn't plugins with assets that aren't pre-compiled be executed
and run through V8 as well?
Eric
···
On Thu, Aug 21, 2014 at 11:52 AM, Lukas Zapletal wrote:
It looks like not allowing the EXECMEM does not hurt Foreman w/ Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule upstream
yesterday but I am going to revert that.
> > Hello,
> >
> > last couple of days, I was chasing down the EXECMEM denial which seems
> > to be quite dangerous to allow for the Passenger process.
> >
> > With great help of Ivan, we were able to identify that it's less-rails
> > dependency that has this kind of behaviour (or faulty code).
> >
> > https://github.com/Katello/katello/blob/master/engines/bastion/lib/bastion.rb#L2
> >
> > It looks like less-rails uses v8 library to do some JavaScript
> > compilation. Ppl with experiences with SCL building know this library
> > very well
> >
> > Couple of questions:
> >
> > - what do we use less-rails for?
>
> The Bastion engine uses LESS as it's stylesheet language along with
> some of the third party (e.g. patternfly) CSS libraries. The
> stylesheets are compiled at build time no different than other assets.
>
> > - do we need to use it during runtime?
>
> No. However, if we want to support asset regeneration then it will
> need to exist.
>
> My questions:
>
> - What is less-rails doing specifically that causes this issue?
> - Why don't we see similar issues given that our JS is compiled through V8?
> - Wouldn't plugins with assets that aren't pre-compiled be executed
> and run through V8 as well?
maybe suggesting to run a rake task to precompile the assets in production
when necessary (but still preferable in the build phase) would be way to go,
as opposed to doing the compilation in runtime.
– Ivan
···
----- Original Message -----
> On Thu, Aug 21, 2014 at 11:52 AM, Lukas Zapletal wrote:
Eric
It looks like not allowing the EXECMEM does not hurt Foreman w/ Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule upstream
yesterday but I am going to revert that.
>
>
>> > Hello,
>> >
>> > last couple of days, I was chasing down the EXECMEM denial which seems
>> > to be quite dangerous to allow for the Passenger process.
>> >
>> > With great help of Ivan, we were able to identify that it's less-rails
>> > dependency that has this kind of behaviour (or faulty code).
>> >
>> > https://github.com/Katello/katello/blob/master/engines/bastion/lib/bastion.rb#L2
>> >
>> > It looks like less-rails uses v8 library to do some JavaScript
>> > compilation. Ppl with experiences with SCL building know this library
>> > very well
>> >
>> > Couple of questions:
>> >
>> > - what do we use less-rails for?
>>
>> The Bastion engine uses LESS as it's stylesheet language along with
>> some of the third party (e.g. patternfly) CSS libraries. The
>> stylesheets are compiled at build time no different than other assets.
>>
>> > - do we need to use it during runtime?
>>
>> No. However, if we want to support asset regeneration then it will
>> need to exist.
>>
>> My questions:
>>
>> - What is less-rails doing specifically that causes this issue?
>> - Why don't we see similar issues given that our JS is compiled through V8?
>> - Wouldn't plugins with assets that aren't pre-compiled be executed
>> and run through V8 as well?
>
> * maybe suggesting to run a rake task to precompile the assets in production
> when necessary (but still preferable in the build phase) would be way to go,
> as opposed to doing the compilation in runtime.
We already do this. There should be no runtime compilation of assets -
we precompile everything which is why I am confused. Sounds like we
are missing something or less-rails is doing compiling assets/running
when it shouldn't.
Eric
···
On Thu, Aug 21, 2014 at 12:55 PM, Ivan Necas wrote:
> ----- Original Message -----
>> On Thu, Aug 21, 2014 at 11:52 AM, Lukas Zapletal wrote:
– Ivan
Eric
It looks like not allowing the EXECMEM does not hurt Foreman w/ Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule upstream
yesterday but I am going to revert that.
> > - What is less-rails doing specifically that causes this issue?
We are not sure, but Ivan was able to identify when this line is
commented out it works in Enforcing.
> > - Why don't we see similar issues given that our JS is compiled through V8?
You mean during the build time? Build phase is running unconfined.
> > - Wouldn't plugins with assets that aren't pre-compiled be executed
> > and run through V8 as well?
Not sure, someone else?
> * maybe suggesting to run a rake task to precompile the assets in production
> when necessary (but still preferable in the build phase) would be way to go,
> as opposed to doing the compilation in runtime.
Ivan, just to doublecheck.
Can you confirm that allowing the EXECMEM does workaround the issue?
> >
> >
> >> > Hello,
> >> >
> >> > last couple of days, I was chasing down the EXECMEM denial which seems
> >> > to be quite dangerous to allow for the Passenger process.
> >> >
> >> > With great help of Ivan, we were able to identify that it's less-rails
> >> > dependency that has this kind of behaviour (or faulty code).
> >> >
> >> > https://github.com/Katello/katello/blob/master/engines/bastion/lib/bastion.rb#L2
> >> >
> >> > It looks like less-rails uses v8 library to do some JavaScript
> >> > compilation. Ppl with experiences with SCL building know this library
> >> > very well
> >> >
> >> > Couple of questions:
> >> >
> >> > - what do we use less-rails for?
> >>
> >> The Bastion engine uses LESS as it's stylesheet language along with
> >> some of the third party (e.g. patternfly) CSS libraries. The
> >> stylesheets are compiled at build time no different than other assets.
> >>
> >> > - do we need to use it during runtime?
> >>
> >> No. However, if we want to support asset regeneration then it will
> >> need to exist.
> >>
> >> My questions:
> >>
> >> - What is less-rails doing specifically that causes this issue?
> >> - Why don't we see similar issues given that our JS is compiled through
> >> V8?
> >> - Wouldn't plugins with assets that aren't pre-compiled be executed
> >> and run through V8 as well?
> >
> > * maybe suggesting to run a rake task to precompile the assets in
> > production
> > when necessary (but still preferable in the build phase) would be way to
> > go,
> > as opposed to doing the compilation in runtime.
>
> We already do this. There should be no runtime compilation of assets -
> we precompile everything which is why I am confused. Sounds like we
> are missing something or less-rails is doing compiling assets/running
> when it shouldn't.
This is the very line that causes the memexec denial:
It's being triggered when calling require 'less-rails' from bastion.rb. It basically
runs the js environment even when there is no compiling needed at the end. Since
it fails here, the whole start of the application fails, because the require 'less-rails'
fails.
So, it seems it might be a good idea to not require 'less-rails' in production, not just
because of the memexec denial, but also for saving some resources (why to load the js runtime
when we don't need that).
We can keep the packages there for the precompilation purposes, but we should not require
that in the production runtime.
– Ivan
···
----- Original Message -----
> On Thu, Aug 21, 2014 at 12:55 PM, Ivan Necas wrote:
> > ----- Original Message -----
> >> On Thu, Aug 21, 2014 at 11:52 AM, Lukas Zapletal wrote:
Eric
– Ivan
Eric
It looks like not allowing the EXECMEM does not hurt Foreman w/ Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule upstream
yesterday but I am going to revert that.
> We already do this. There should be no runtime compilation of assets -
> we precompile everything which is why I am confused. Sounds like we
> are missing something or less-rails is doing compiling assets/running
> when it shouldn't.
I was trying to track files being written during tasks boot on Friday
but was not able to find anything. We are not sure if assets are being
compiled actually, the fact is something (wrong) is going on in
therubyracer/v8 engine (executing some memory bits).
While allowing this could be the only way how to get v8 running in
SELinux enforcing (and it looks like Firefox does have the same rule),
we should rather try to fix the cause. It is unnecessary to compile
things during the boot time.
Eric if you need further testing ping me. Can build policy without this
rule to reproduce this for you.
Yes, I was about to say, you don't need those in production. Foreman has an
:assets group that is only loaded for the rake assets:precompile build
phase:
···
On Fri, Aug 22, 2014 at 4:51 AM, Ivan Necas wrote:
----- Original Message -----
On Thu, Aug 21, 2014 at 12:55 PM, Ivan Necas inecas@redhat.com wrote:
----- Original Message -----
On Thu, Aug 21, 2014 at 11:52 AM, Lukas Zapletal lzap@redhat.com > wrote:
Hello,
last couple of days, I was chasing down the EXECMEM denial which
seems
to be quite dangerous to allow for the Passenger process.
With great help of Ivan, we were able to identify that it’s
less-rails
dependency that has this kind of behaviour (or faulty code).
It looks like less-rails uses v8 library to do some JavaScript
compilation. Ppl with experiences with SCL building know this
library
very well
Couple of questions:
what do we use less-rails for?
The Bastion engine uses LESS as it’s stylesheet language along with
some of the third party (e.g. patternfly) CSS libraries. The
stylesheets are compiled at build time no different than other assets.
do we need to use it during runtime?
No. However, if we want to support asset regeneration then it will
need to exist.
My questions:
What is less-rails doing specifically that causes this issue?
Why don’t we see similar issues given that our JS is compiled
through
V8?
Wouldn’t plugins with assets that aren’t pre-compiled be executed
and run through V8 as well?
maybe suggesting to run a rake task to precompile the assets in
production
when necessary (but still preferable in the build phase) would be
way to
go,
as opposed to doing the compilation in runtime.
We already do this. There should be no runtime compilation of assets -
we precompile everything which is why I am confused. Sounds like we
are missing something or less-rails is doing compiling assets/running
when it shouldn’t.
This is the very line that causes the memexec denial:
It’s being triggered when calling require 'less-rails' from bastion.rb.
It basically
runs the js environment even when there is no compiling needed at the end.
Since
it fails here, the whole start of the application fails, because the require 'less-rails'
fails.
So, it seems it might be a good idea to not require ‘less-rails’ in
production, not just
because of the memexec denial, but also for saving some resources (why to
load the js runtime
when we don’t need that).
We can keep the packages there for the precompilation purposes, but we
should not require
that in the production runtime.
– Ivan
Eric
– Ivan
Eric
It looks like not allowing the EXECMEM does not hurt Foreman w/
Katello
plugin as it operates normally. There were some reports tho of
application not booting up. Under pressure, I merged this rule
upstream
yesterday but I am going to revert that.
–
Later,
Lukas #lzap Zapletal
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
> > > - What is less-rails doing specifically that causes this issue?
>
> We are not sure, but Ivan was able to identify when this line is
> commented out it works in Enforcing.
>
> > > - Why don't we see similar issues given that our JS is compiled through
> > > V8?
>
> You mean during the build time? Build phase is running unconfined.
>
> > > - Wouldn't plugins with assets that aren't pre-compiled be executed
> > > and run through V8 as well?
>
> Not sure, someone else?
>
> > * maybe suggesting to run a rake task to precompile the assets in
> > production
> > when necessary (but still preferable in the build phase) would be way to
> > go,
> > as opposed to doing the compilation in runtime.
>
> Ivan, just to doublecheck.
>
> Can you confirm that allowing the EXECMEM does workaround the issue?
It seems to workaround the issue with the less-rails.
