This is run from a sudo environment (as root user). Theres really very
little I can do about that aspect.
Anyway. The problem occurs when "install_rvm.rb" calls the following
installer:
system "/usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/"
The installer installs its files to --prefix "/usr/local/rvm/". However
all those files it creates / copies are somehow all UID 501? But theres
no UID 501 on the computer? ?? This supposed user doesnt actually exist.
The bash installer script itself does not cause this. Eg if i run from
the commandline:
This is run from a sudo environment (as root user). Theres really very
little I can do about that aspect.
Anyway. The problem occurs when "install_rvm.rb" calls the following
installer:
system "/usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/"
The installer installs its files to --prefix "/usr/local/rvm/". However
all those files it creates / copies are somehow all UID 501? But theres
no UID 501 on the computer? ?? This supposed user doesnt actually exist.
The bash installer script itself does not cause this. Eg if i run from
the commandline:
I expect this to be a bug in Ruby. Because theres no username associated
with the UID 501:
First, I love how you jump to the conclusion that it's a Ruby bug even
though you are using a second generation install script that has nothing to
do with Ruby. It's all fine and great to use helper scripts to organize the
installation of something but a flaw in the script does not equal a flaw in
the tool being installed.
There is no requirement that an actual user be associated with an id for the
id to own an object. That's sort of why you see 501 as the user as opposed
to the user name. It appears that the script is using the concept of group
ownership as the controlling factor as opposed to worrying about the user id
of the file owners. In other words once the tarball is opened up they are
changing the group owner of the files to something it knows exists but not
worrying about the user id. You could easily run chown -R "whatever user you
choose" /usr/local/rvm and you would then not see the 501 user.
Or you could patch your install script and contribute it back.
It does appear that the tarball maybe comes from OSX where 501 is a well
known user id and therefore normally exists. I have CentOS boxes that appear
to start at 501 and Gentoo boxes that appear to start at 1001 so it's just
an oversight in the install script you are looking at but it's not something
I would loose sleep over - and if you are inclined to do so then just run
the chown command above.
John
···
On Thu, Nov 18, 2010 at 4:57 AM, Dreamcat Four <dreamcat4@gmail.com> wrote:
when the script apparently also uses sudo. Do you have an explanation?
Kind regards
robert
···
On 18.11.2010 18:32, John W Higgins wrote:
It does appear that the tarball maybe comes from OSX where 501 is a well
known user id and therefore normally exists. I have CentOS boxes that appear
to start at 501 and Gentoo boxes that appear to start at 1001 so it's just
an oversight in the install script you are looking at but it's not something
I would loose sleep over - and if you are inclined to do so then just run
the chown command above.
when the script apparently also uses sudo. Do you have an explanation?
While I don't even use rvm myself - it clearly is a very smart little set of
widgets that could easily be smart enough to differentiate the difference
between running it as sudo/root and a regular user. It's very possible that
it runs a chown to root only when run as sudo/root. That clearly is within a
reasonable distance from the rest of the magic being performed here. And
performed very very well it appears.
John
···
On Thu, Nov 18, 2010 at 11:30 PM, Robert Klemme <shortcutter@googlemail.com>wrote:
It does appear that the tarball maybe comes from OSX where 501 is a well
known user id and therefore normally exists. I have CentOS boxes that appear
to start at 501 and Gentoo boxes that appear to start at 1001 so it's just
an oversight in the install script you are looking at but it's not something
I would loose sleep over - and if you are inclined to do so then just run
the chown command above.
Granted, this can easily be fixed with chown. I'm not sure I understand
how this can produce the difference between
system "/usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/"
when the script apparently also uses sudo. Do you have an explanation?
Hi Robert,
Like John - I also haven't bothered to look into this properly and am
just speculating now at this point. Since my original post, i've
re-written my ruby script to do some fancy things. You can see it all in
the same gist which has been heavily updated. Dropping the root
permissions with:
Solves the problem. Sudo is used sparingly to do 'level back up again'
for any chgrp / chowning afterwards.
The thing about this user 501 permissions - is that many of us have seen
it happen before with the `tar` program. A tarball is created on the
developer's computer. And for whatever reason when the files are
unpacked on another computer they have the original permissions which
were stored in the tarball.
Perhaps the tar program differentiates between the root user, and a
regular user. For example - a regular user cannot create new files with
the UID 501 - its impossible because they dont have the privelidge. So
in those cases tar must create the files assumed under the current users
UID.
Wheras if tar is invoked by a process UID=0 (the root user), then
clearly tar will be allowed to create 501 UID owned files.