How do we fix gem permissions?

I just recently tried a system rvm installation, as I want to run some
Ruby
scripts as isolated users who really don’t need their own rvm or gems.

Here’s the problem:

Gem permissions are retarded these days.

It seems like a gem is a tarball which wraps another couple of gzipped
tarballs (really?), one of which is unpacked to the gem’s final
destination.
Then some things are compiled if necessary, but the permissions are
pretty
much what the tarball sets.

That’s useful when you want to have a binary file in bin, say, and you
can
just make it executable with chmod and the tarball will carry that
through to
the end-user.

It’s problematic when I see this:

$ find $GEM_HOME/gems/x11-0.0.1a2 ! -perm /0044 | wc -l
130

Unless I’m missing something, this tells me that there are 130 files
which the
author of the ‘x11’ gem thinks that only the gem admin should be able to
read.

To turn it around:

$ find $GEM_HOME/gems/x11-0.0.1a2 -perm /0044 | wc -l
21

In other words, there are only 21 files which can be read by a single
user
other than the person who installs gems. I cannot imagine this is what
was
intended, and my usual recipe for fixing this is:

$ find $GEM_HOME/gems/x11-0.0.1a2 -type f -exec chmod 644 ‘{}’ ;
$ find $GEM_HOME/gems/x11-0.0.1a2 -type d -exec chmod 755 ‘{}’ ;

…then fix anything that needs execute permission.

Since most of us have gone the lazy rvm-in-homedir way, this doesn’t
show up
during gem development, but I imagine this violates the principle of
least
surprise for a lot of people – you build a gem which works fine on your
machine, and on all the dev machines, until someone tries to deploy it
to a
proper staging/test system with system gems, or until a developer wants
system
gems. Then, suddenly, you get stuff like this:

require ‘retarded’
LoadError: no such file to load – retarded

I’m not making that up – the gem is actually called ‘retarded’, and
it’s only
a single file which my non-root user cannot load because someone set
some
screwy file permissions at some point.

Assuming I’m not the only person who cares about being able to install
gems
system-wide, or having gem permissions be sane on other machines, is
there a
good way to fix this? It seems to me that the obvious solution is to
have
files be mode 644, directories 755, unless explicitly overridden, maybe
with
some common shortcuts for making scripts executable – and we already
handle
scripts specially anyway. In fact, I can’t think of a single reason a
gem ever
needs anything to have permissions other than this.

Probably the least disruptive fix would be to change the gem building
process,
rather than the gem format. Tar is a perfectly fine format for storing
file
permissions, it’s just that we shouldn’t be getting them originally from
the
filesystem. It’d also be nice to have commandline options to override
the
tarball’s permissions with what we can guess, in a similar way.

On Aug 11, 2011, at 5:44 PM, David M. wrote:

Probably the least disruptive fix would be to change the gem building process,
rather than the gem format. Tar is a perfectly fine format for storing file
permissions, it’s just that we shouldn’t be getting them originally from the
filesystem. It’d also be nice to have commandline options to override the
tarball’s permissions with what we can guess, in a similar way.

lolcat had this problem too due to the packager’s umask (I think).
RubyGems should at least warn if files are readable/writable only by
root.

Remember! When you think it’s a bug, file a bug in the ticket tracker.
Here’s the URL for RubyGems:

https://github.com/rubygems/rubygems/issues