You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by dj...@apache.org on 2009/06/15 20:14:37 UTC
svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Author: djspiewak
Date: Mon Jun 15 18:14:37 2009
New Revision: 784896
URL: http://svn.apache.org/viewvc?rev=784896&view=rev
Log:
Added RAKE_SUDO envar override (for e.g. non-global JRuby installations)
Modified:
buildr/trunk/rakelib/setup.rake
Modified: buildr/trunk/rakelib/setup.rake
URL: http://svn.apache.org/viewvc/buildr/trunk/rakelib/setup.rake?rev=784896&r1=784895&r2=784896&view=diff
==============================================================================
--- buildr/trunk/rakelib/setup.rake (original)
+++ buildr/trunk/rakelib/setup.rake Mon Jun 15 18:14:37 2009
@@ -17,6 +17,12 @@
require 'jruby' if RUBY_PLATFORM[/java/]
require 'rubygems/source_info_cache'
+RAKE_SUDO = case (ENV['RAKE_SUDO'] or 'yes').strip.downcase
+ when 'yes', 'true'
+ true
+ else
+ false
+end
# Install the specified gem. Options include:
# - :version -- Version requirement, e.g. '1.2' or '~> 1.2'
@@ -27,7 +33,7 @@
puts "Installing #{name} ..."
rb_bin = File.join(Config::CONFIG['bindir'], Config::CONFIG['ruby_install_name'])
args = []
- args << 'sudo' << 'env' << "JAVA_HOME=#{ENV['JAVA_HOME']}" if sudo_needed?
+ args << 'sudo' << 'env' << "JAVA_HOME=#{ENV['JAVA_HOME']}" if sudo_needed? and RAKE_SUDO
args << rb_bin << '-S' << 'gem' << 'install' << name
args << '--version' << dep.version_requirements.to_s
args << '--source' << options[:source] if options[:source]
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Assaf Arkin <ar...@intalio.com>.
On Tue, Jun 23, 2009 at 6:07 PM, Stephen Bannasch <
stephen.bannasch@deanbrook.org> wrote:
> At 2:29 PM -0700 6/15/09, Assaf Arkin wrote:
>
>> And I agree about the "convenience install pack" of JRuby
>> having no notion of security practices. It's the equivalent of getting a
>> Linux box and running IE8 as your default browser.
>>
>
> That's a major misunderstanding of the function and purpose for installing
> jruby into userspace.
The term userspace refers to anything that's not kernel, kernel module or
device driver[1], so we're all talking about installing JRuby to execute in
userspace. The option is whether to install executables in a place that your
account is privileged to modify without your consent [2].
Allowing executables to change without explicit user consent is the default
setting in Windows XP, and a factor in many of its security vulnerabilities
[3]. Of course not everyone appreciate the added annoyance, when Windows
Vista introduced a revised security architecture many people complained [4].
Like most people I don't like inconvenience if I don't understand the
security implications.
On Linux, OS X and other UN*X variants, you simply place your executables in
any of the directories designated for holding binaries [5] (specific paths
change between UN*X variants but broadly they all work the same).
When it comes to convenience vs security, I err on the side of security, I
also like to allow acts of convenience. I'm not recommending that Buildr
fails when invoked or loading code from a vulnerable path (e.g. SSH will do
that).
I am recommending that the default path we present to people always favors
their security over their convenience, so they can choose differently, but
if they place their trust in us, we return that trust.
Assaf
[1] http://en.wikipedia.org/wiki/User_space
[2] http://en.wikipedia.org/wiki/Sudo
[3] http://en.wikipedia.org/wiki/Criticism_of_Windows_XP
[4] http://en.wikipedia.org/wiki/User_Account_Control
[5] http://en.wikipedia.org/wiki/Sbin
>
>
> I have 4 different jruby instances installed in different directories in
> userspace on my development system. I often create new ones just to test
> installation of a set of dependencies for a specific application. I have one
> which is the most recent stable jruby release, another which is trunk.
>
> Installing jruby into a userspace directory makes it much easier to delete
> when I don't need it anymore. It also makes it easier to use right along
> side MRI ruby. I am often running a rails app in jruby and debugging it in
> MRI.
>
> I also have rubinius, macruby, and ruby19 also installed in separate
> userspace directories and I test and run benchmarks on all these systems.
>
> None of these installations are installed in /usr/bin or /usr/local/bin --
> I save those for the 'system' ruby -- in my case it is MRI.
>
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Stephen Bannasch <st...@deanbrook.org>.
At 2:29 PM -0700 6/15/09, Assaf Arkin wrote:
>And I agree about the "convenience install pack" of JRuby
>having no notion of security practices. It's the equivalent of getting a
>Linux box and running IE8 as your default browser.
That's a major misunderstanding of the function and purpose for
installing jruby into userspace.
I have 4 different jruby instances installed in different directories
in userspace on my development system. I often create new ones just
to test installation of a set of dependencies for a specific
application. I have one which is the most recent stable jruby
release, another which is trunk.
Installing jruby into a userspace directory makes it much easier to
delete when I don't need it anymore. It also makes it easier to use
right along side MRI ruby. I am often running a rails app in jruby
and debugging it in MRI.
I also have rubinius, macruby, and ruby19 also installed in separate
userspace directories and I test and run benchmarks on all these
systems.
None of these installations are installed in /usr/bin or
/usr/local/bin -- I save those for the 'system' ruby -- in my case it
is MRI.
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Daniel Spiewak <dj...@gmail.com>.
> I mean installing in /opt (or /usr/local for that matter) and allowing all
> users to have access, as opposed to installing in ~/bin or similar.
>
By "access" I mean read-only. There is no need for the JRUBY_HOME directory
to be read/write for anyone (except those who need to install gems).
Daniel
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Jun 15, 2009 at 7:13 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> > I'm not sure what non-global has to do with it (or even what it means).
>
>
> I mean installing in /opt (or /usr/local for that matter) and allowing all
> users to have access, as opposed to installing in ~/bin or similar.
>
>
> > From the jruby.org web site (but also just about any other JRuby
> > documentation I read):
> >
> > 1. Extract JRuby into a directory.
> > 2. Add that directory's bin subdirectory to the end of your path.
> > 3. Test it: jruby -v
>
>
> "Yes" to the above, "no" to the below.
>
> They expect you to add a user writable directory to your path.
>
>
> This really isn't too different from how *any* *nix tool is distributed in
> binary form. We've gotten used to most things coming as source with an
> autoconf script generating a makefile, but there are still one or two
> useful
> packages which only provide pre-compiled binaries. In such cases, the
> distribution mechanism of choice is *usually* a tarball which is extracted
> into the required directory. Why would you need an installer to run two
> commands?
Because it does the right thing, and when it does the right thing, the right
thing happens to more people and more often.
$ ls -al _buildr
-rwxr-xr-x 1 assaf staff 1.3K Mar 12 23:31 _buildr
$ cd buildr
$ sudo cp _buildr /usr/bin
$ ls -al /usr/bin/_buildr
-rwxr-xr-x 1 root wheel 1.3K Jun 15 20:40 /usr/bin/_buildr
Or maybe you don't want /usr/bin (OS upgrade will write over it), and you
don't want to copy, you prefer symlinks:
$ sudo ln -s _buildr /opt/local/bin/
$ ls -al /opt/local/bin/_buildr
lrwxr-xr-x 1 root admin 7B Jun 15 20:56 /opt/local/bin/_buildr ->
_buildr
Same effect. All you need is a properly setup bin directory and place your
executables there. It may be accessible only to you or shared with everyone,
either way only sudo can change executables. Even if you're the only account
with read/write privileges, you're closing a vector of attack..
As a single install step, placing in bin affords you more security than
adding odd directories to path.
Assaf
>
> From what I know of the JRuby community, the conventional install follows
> one of two paths. For the personal development machine with one user (e.g.
> my laptop), it's usually easiest to install JRuby under the home directory,
> user read/write where changes can be made as necessary. I've edited the
> JRuby startup scripts on more than one occasion, and I used to actually
> work
> directly from the SVN sources. Both of these tasks are made a lot easier
> when I have easy read/write access to JRUBY_HOME.
>
> The other option is a server or a shared workstation. In either case, the
> conventional approach is to install JRuby just like any other *nix package:
> in /usr/local or /opt, according to taste. From there, the binaries can be
> symlinked into /usr/local/bin, or simply placed on the PATH.
>
> They (meaning the JRuby team) don't really *expect* one case or another.
> They have merely provided the simplest possible setup instructions. I
> think
> they probably assume that competent *nix hackers will be more than capable
> of placing the install wherever they please. Now, Eclipse on the other
> hand... ;-)
>
> Daniel
>
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Daniel Spiewak <dj...@gmail.com>.
> I'm not sure what non-global has to do with it (or even what it means).
I mean installing in /opt (or /usr/local for that matter) and allowing all
users to have access, as opposed to installing in ~/bin or similar.
> From the jruby.org web site (but also just about any other JRuby
> documentation I read):
>
> 1. Extract JRuby into a directory.
> 2. Add that directory's bin subdirectory to the end of your path.
> 3. Test it: jruby -v
"Yes" to the above, "no" to the below.
They expect you to add a user writable directory to your path.
This really isn't too different from how *any* *nix tool is distributed in
binary form. We've gotten used to most things coming as source with an
autoconf script generating a makefile, but there are still one or two useful
packages which only provide pre-compiled binaries. In such cases, the
distribution mechanism of choice is *usually* a tarball which is extracted
into the required directory. Why would you need an installer to run two
commands?
>From what I know of the JRuby community, the conventional install follows
one of two paths. For the personal development machine with one user (e.g.
my laptop), it's usually easiest to install JRuby under the home directory,
user read/write where changes can be made as necessary. I've edited the
JRuby startup scripts on more than one occasion, and I used to actually work
directly from the SVN sources. Both of these tasks are made a lot easier
when I have easy read/write access to JRUBY_HOME.
The other option is a server or a shared workstation. In either case, the
conventional approach is to install JRuby just like any other *nix package:
in /usr/local or /opt, according to taste. From there, the binaries can be
symlinked into /usr/local/bin, or simply placed on the PATH.
They (meaning the JRuby team) don't really *expect* one case or another.
They have merely provided the simplest possible setup instructions. I think
they probably assume that competent *nix hackers will be more than capable
of placing the install wherever they please. Now, Eclipse on the other
hand... ;-)
Daniel
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Jun 15, 2009 at 2:38 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> > And I agree about the "convenience install pack" of JRuby
> > having no notion of security practices. It's the equivalent of getting a
> > Linux box and running IE8 as your default browser.
>
>
> Not to take things too far off-topic, but I'm not sure how JRuby's
> non-global installation could be considered insecure or bad practice in any
> way. I run numerous tools and utilities from within userspace just out of
> convenience. If I were to install JRuby on a multi-user box or server (and
> I have), then I would probably stick it in /opt and chown it to root.
> JRuby
> works fine in this case, I would simply need to use sudo whenever using gem
> (just as with MRI).
>
> So, I guess I'm not sure what you're saying here regarding JRuby's lack of
> security practices, seeing as it is every bit as capable as MRI in terms of
> install configuration, but with the added benefit of allowing non-global
> installations without fuss.
I'm not sure what non-global has to do with it (or even what it means).
>From the jruby.org web site (but also just about any other JRuby
documentation I read):
1. Extract JRuby into a directory.
2. Add that directory's bin subdirectory to the end of your path.
3. Test it: jruby -v
They expect you to add a user writable directory to your path.
You can, and should, chown that directory or use apt or macports (either one
will set owner/permission for you), but that's not what the homepage
advocates. There's no bundled installer to do it for you.
Assaf
>
>
> Daniel
>
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Daniel Spiewak <dj...@gmail.com>.
> And I agree about the "convenience install pack" of JRuby
> having no notion of security practices. It's the equivalent of getting a
> Linux box and running IE8 as your default browser.
Not to take things too far off-topic, but I'm not sure how JRuby's
non-global installation could be considered insecure or bad practice in any
way. I run numerous tools and utilities from within userspace just out of
convenience. If I were to install JRuby on a multi-user box or server (and
I have), then I would probably stick it in /opt and chown it to root. JRuby
works fine in this case, I would simply need to use sudo whenever using gem
(just as with MRI).
So, I guess I'm not sure what you're saying here regarding JRuby's lack of
security practices, seeing as it is every bit as capable as MRI in terms of
install configuration, but with the added benefit of allowing non-global
installations without fuss.
Daniel
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Jun 15, 2009 at 12:17 PM, Daniel Spiewak <dj...@gmail.com>wrote:
> > Buildr depends on several Gems that install executables (rake, spec,
> etc).
> > It is a good idea to not have write permission on directories containing
> > executables (part of the security architecture of Unix and its
> > derivatives).
> > For the general case you need to use sudo to install Buildr and its
> > dependencies, it might be annoying, but it's keeping to the security
> > architecture.
> >
> > That should be the default behavior.
>
>
> The default behavior *is* to use sudo; this doesn't change that. What it
> does is provide a hook so that I can run `rake setup` without having to
> edit
> the rakelib files every time. :-) I use JRuby, and I have it installed in
> a non-global directory (it's under ~). As such, I really need to install
> gems *without* using sudo, otherwise permissions get screwed up.
> Considering the fact that JRuby encourages installation in non-global
> locations, this really isn't an unusual use case. When installing Buildr
> using `gem`, I can just invoke gem without sudo. However, `rake setup`
> doesn't give me that option. That's what this commit was designed to
> allow.
Since this is just rake setup and not well advertised feature (it won't show
up if you do rake --tasks), I'm over-reacting.
And I agree about the "convenience install pack" of JRuby
having no notion of security practices. It's the equivalent of getting a
Linux box and running IE8 as your default browser.
Assaf
>
>
> > Also, avoid using 'or' and 'and' in expression (they're fine as statement
> > separators). 99% of the time they work just like && and ||, but every
> once
> > in a while they're used without paying attention to operator precedence
> and
> > we end up with subtle and hard to find bugs.
>
>
> Noted for future reference. I knew that Rails avoids 'and' and 'or', but I
> had never heard a compelling reason why.
>
> Daniel
>
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Daniel Spiewak <dj...@gmail.com>.
> Buildr depends on several Gems that install executables (rake, spec, etc).
> It is a good idea to not have write permission on directories containing
> executables (part of the security architecture of Unix and its
> derivatives).
> For the general case you need to use sudo to install Buildr and its
> dependencies, it might be annoying, but it's keeping to the security
> architecture.
>
> That should be the default behavior.
The default behavior *is* to use sudo; this doesn't change that. What it
does is provide a hook so that I can run `rake setup` without having to edit
the rakelib files every time. :-) I use JRuby, and I have it installed in
a non-global directory (it's under ~). As such, I really need to install
gems *without* using sudo, otherwise permissions get screwed up.
Considering the fact that JRuby encourages installation in non-global
locations, this really isn't an unusual use case. When installing Buildr
using `gem`, I can just invoke gem without sudo. However, `rake setup`
doesn't give me that option. That's what this commit was designed to allow.
> Also, avoid using 'or' and 'and' in expression (they're fine as statement
> separators). 99% of the time they work just like && and ||, but every once
> in a while they're used without paying attention to operator precedence and
> we end up with subtle and hard to find bugs.
Noted for future reference. I knew that Rails avoids 'and' and 'or', but I
had never heard a compelling reason why.
Daniel
Re: svn commit: r784896 - /buildr/trunk/rakelib/setup.rake
Posted by Assaf Arkin <ar...@intalio.com>.
Buildr depends on several Gems that install executables (rake, spec, etc).
It is a good idea to not have write permission on directories containing
executables (part of the security architecture of Unix and its derivatives).
For the general case you need to use sudo to install Buildr and its
dependencies, it might be annoying, but it's keeping to the security
architecture.
That should be the default behavior.
Also, avoid using 'or' and 'and' in expression (they're fine as statement
separators). 99% of the time they work just like && and ||, but every once
in a while they're used without paying attention to operator precedence and
we end up with subtle and hard to find bugs.
Assaf
On Mon, Jun 15, 2009 at 11:14 AM, <dj...@apache.org> wrote:
> Author: djspiewak
> Date: Mon Jun 15 18:14:37 2009
> New Revision: 784896
>
> URL: http://svn.apache.org/viewvc?rev=784896&view=rev
> Log:
> Added RAKE_SUDO envar override (for e.g. non-global JRuby installations)
>
> Modified:
> buildr/trunk/rakelib/setup.rake
>
> Modified: buildr/trunk/rakelib/setup.rake
> URL:
> http://svn.apache.org/viewvc/buildr/trunk/rakelib/setup.rake?rev=784896&r1=784895&r2=784896&view=diff
>
> ==============================================================================
> --- buildr/trunk/rakelib/setup.rake (original)
> +++ buildr/trunk/rakelib/setup.rake Mon Jun 15 18:14:37 2009
> @@ -17,6 +17,12 @@
> require 'jruby' if RUBY_PLATFORM[/java/]
> require 'rubygems/source_info_cache'
>
> +RAKE_SUDO = case (ENV['RAKE_SUDO'] or 'yes').strip.downcase
> + when 'yes', 'true'
> + true
> + else
> + false
> +end
>
> # Install the specified gem. Options include:
> # - :version -- Version requirement, e.g. '1.2' or '~> 1.2'
> @@ -27,7 +33,7 @@
> puts "Installing #{name} ..."
> rb_bin = File.join(Config::CONFIG['bindir'],
> Config::CONFIG['ruby_install_name'])
> args = []
> - args << 'sudo' << 'env' << "JAVA_HOME=#{ENV['JAVA_HOME']}" if
> sudo_needed?
> + args << 'sudo' << 'env' << "JAVA_HOME=#{ENV['JAVA_HOME']}" if
> sudo_needed? and RAKE_SUDO
> args << rb_bin << '-S' << 'gem' << 'install' << name
> args << '--version' << dep.version_requirements.to_s
> args << '--source' << options[:source] if options[:source]
>
>
>