Calling a bash script creates files as UID 501 ?

[Dreamcat Four]

Hi,

I have to run an installer script on the system, via ruby.

ruby -e "$(curl -fsS https://gist.github.com/raw/542746/install_rvm.rb)"

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:

sudo /usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/

Then all the files are created all as user "root" (UID=0). What could be
happening here?


dreamcat4
(e-mail address removed)

 

[Robert Klemme]

Hi,

I have to run an installer script on the system, via ruby.

ruby -e "$(curl -fsS https://gist.github.com/raw/542746/install_rvm.rb)"

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:

sudo /usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/

Then all the files are created all as user "root" (UID=0). What could be
happening here?

Hm... What does "ls -l /usr/local/rvm/src/rvm/scripts/install" print?

Cheers

robert

 

[Dreamcat Four]

Robert Klemme wrote in post #962330:

Hm... What does "ls -l /usr/local/rvm/src/rvm/scripts/install" print?

-rwxr-xr-x 1 root root 13716 2010-11-18 12:48
/usr/local/rvm/src/rvm/scripts/install

 

[Dreamcat Four]

Just also to mention that -

The OS is ubuntu 10.10 Maverick, and the ruby version is

ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-linux]

(`aptitude install -y ruby`)


I expect this to be a bug in Ruby. Because theres no username associated
with the UID 501:

root@vagrant-ubuntu-maverick:/vagrant# irb
irb(main):001:0> require 'etc'
=> true
irb(main):003:0> Etc.getpwuid 501
ArgumentError: can't find user for 501
from (irb):3:in `getpwuid'
from (irb):3
from :0
irb(main):004:0>


What do you think?

dreamcat4
(e-mail address removed)

 

[Jose Hales-Garcia]

Just also to mention that -
=20
The OS is ubuntu 10.10 Maverick, and the ruby version is
=20
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-linux]

Is there a OS X compatibility mode in Ubuntu? 501 is the UID assigned =
the first user account (and admin by default) in OS X.

Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
(e-mail address removed)

 

[John W Higgins]

[Note: parts of this message were removed to make it a legal post.]

Good Morning,

Just also to mention that -

The OS is ubuntu 10.10 Maverick, and the ruby version is

ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-linux]

(`aptitude install -y ruby`)


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

 

[Dreamcat Four]

John W Higgins wrote in post #962380:

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

Ah,
So if the tar cmd is untaring files with the same UID as were created on
original system. Thanks! That makes a ton more sense now.

I believe there's flags for tar which control this.


dreamcat4
(e-mail address removed)

 

[Robert Klemme]

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/"

and

sudo /usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/

when the script apparently also uses sudo. Do you have an explanation?

Kind regards

robert

 

[John W Higgins]

[Note: parts of this message were removed to make it a legal post.]

Good Evening,

... 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/"

and


sudo /usr/local/rvm/src/rvm/scripts/install --prefix /usr/local/rvm/

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

 

[Dreamcat Four]

Robert Klemme wrote in post #962523:

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/"

and

sudo /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:

Process::sys.setgid(admin_group)
Process::sys.setuid(Etc.getlogin)

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.