not user install

[GoogleCodeExporter]

Hello,
I have to install pdsh in a cluster, where I not have root permission, with a 
particular user (userfoo).
But the application has to be used  by all other user (myuser).
It is possible to install pdsh with these conditions?
I configure with --with-ssh --prefix=/opt/appli/pdsh/2.22 

When I type pdsh, I get: 
userfoo> module path "/opt/appli/pdsh/2.22/lib/pdsh" insicure
userfoo> "/opt/appli": World writable and sticky bit is not set
userfoo> Couldn't load any pdsh module

or
myuser>  module path "/opt/appli/pdsh/2.22/lib/pdsh" insicure
myuser>  module path "/opt/appli/pdsh/2.22/lib/pdsh": Owner not root, current 
uid, or pdsh executable owner
userfoo> Couldn't load any pdsh module

Original issue reported on code.google.com by man74...@gmail.com on 5 Apr 2011 at 10:23

[GoogleCodeExporter]

The problem is that pdsh is being paranoid about the path
from which it loads dynamically loaded modules. Since pdsh will
load any module it finds in /opt/appli/pdsh/2.22/lib/pdsh/*.so,
it is dangerous to run and execute code from these objects
if the path is owned by someone other than root or the pdsh
executable owner. The entire path all the way back to /opt
must have secure ownership, otherwise a user could change
directories leading up to the lib/pdsh directory and replace
or modify modules.

The main problem here seems to be that /opt/appli is a world
writable directory without the sticky bit set. Setting the sticky
bit on that directory would help because otherwise any user
can delete and rename directories and files in /opt/appli.

I am a bit confused by the error here:

 module path "/opt/appli/pdsh/2.22/lib/pdsh": Owner not root, current uid, or pdsh executable owner

I would have assumed that you installed the pdsh executable as 'userfoo' so the
directory /opt/appli/pdsh/2.22/lib/pdsh and all the modules should also be
owned by 'userfoo'. Could you check on that?

Original comment by mark.gro...@gmail.com on 5 Apr 2011 at 1:28

[GoogleCodeExporter]

Hello,
thanks for your answer.

> I would have assumed that you installed the pdsh executable as 
> 'userfoo' so the directory /opt/appli/pdsh/2.22/lib/pdsh and all the 
> modules should also be owned by 'userfoo'. Could you check on that?

yes all modules have  userfoo as owner.
But this is the result of the command with "myuser".

Concerning the installation. I have that /opt is root while /opt/appli is all 
world writable. Do you know if there is a workaround.
I can't change permission of /opt and /opt/appli.

Best regards,
Marco

Original comment by man74...@gmail.com on 5 Apr 2011 at 2:58

[GoogleCodeExporter]

> yes all modules have  userfoo as owner.
> But this is the result of the command with "myuser".

If userfoo is the owner of all pdsh install files I wouldn't expect to see
the error:

 module path "/opt/appli/pdsh/2.22/lib/pdsh": Owner not root, current uid, or pdsh executable owner

because pdsh owner uid should == uid of that directory. I should test the code
to verify this is working correctly.

>
> Concerning the installation. I have that /opt is root while /opt/appli is all 
world > writable. Do you know if there is a workaround.
> I can't change permission of /opt and /opt/appli.

I could add a compile-time flag to configure: --without-path-permission-check
to allow your install to work. It is not ideal though. Perhaps you can ask the
administrator of your system to set the sticky bit on /opt/appli?

Original comment by mark.gro...@gmail.com on 5 Apr 2011 at 4:34

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I just tested install into world-writable directory as non-root user and
it seems to work as long as the sticky bit is set on the world-writable
directory:

 mark@wednesday:~$ whoami
 mark
 mark@wednesday:~$ ls -l /tmp/pdsh/2.25/bin/pdsh
 -rwxr-xr-x 1 grondo grondo 421159 2011-04-05 09:41 /tmp/pdsh/2.25/bin/pdsh
 mark@wednesday:~$ ls -ld /tmp/pdsh/2.25/lib
 drwxr-xr-x 3 grondo grondo 4096 2011-04-05 09:39 /tmp/pdsh/2.25/lib
 mark@wednesday:~$ ls -ld /tmp/pdsh/2.25
 drwxr-xr-x 6 grondo grondo 4096 2011-04-05 09:39 /tmp/pdsh/2.25
 mark@wednesday:~$ ls -ld /tmp/pdsh/
 drwxr-xr-x 3 grondo grondo 4096 2011-04-05 09:39 /tmp/pdsh/
 mark@wednesday:~$ ls -ld /tmp/
 drwxrwxrwt 20 root root 20480 2011-04-05 09:42 /tmp/ 

 mark@wednesday:~$ /tmp/pdsh/2.25/bin/pdsh -V
 pdsh-2.25 (+debug)
 rcmd modules: ssh,rsh,exec (default: rsh)
 misc modules: machines,dshgroup (*conflicting: netgroup)
 [* To force-load a conflicting module, use the -M <name> option]

If I remove the sticky bit from /tmp, then I get the expected failure:

 mark@wednesday:~$ /tmp/pdsh/2.25/bin/pdsh -V
 pdsh@wednesday: module path "/tmp/pdsh/2.25/lib/pdsh" insecure.
 pdsh@wednesday: "/tmp": World writable and sticky bit is not set
 pdsh@wednesday: Couldn't load any pdsh modules
 mark@wednesday:~$ ls -ld /tmp/
 drwxrwxrwx 20 root root 20480 2011-04-05 09:42 /tmp/

Original comment by mark.gro...@gmail.com on 5 Apr 2011 at 4:47

[GoogleCodeExporter]

I could, I have to ask to the administrator, to set the sticky bit for 
/opt/appli,
but surely not for /opt.
I will test it.

The compilation flag seems a good solution
--without-path-permission-check
What are the risks of that?

Another question.
Trying the installation I installed pdsh on my home on two different cluster 
(and 2 different home).
In the first psdh works fine but the executables have root ownership
In the second the owner of the executables is me but pdsh doesn't work.
Any idea?

Original comment by man74...@gmail.com on 6 Apr 2011 at 4:25

[GoogleCodeExporter]

Hello,
I resolved my problem by modifying the source pdsh/src/mod.c
I commented the control on permission:
from line 888 to 892
from line 981 to 988
from line 1062 to 1070
and changing the ownership of the executable with the installing user one.
What do you thin about it?
Marco

Original comment by man74...@gmail.com on 6 Apr 2011 at 8:19

[GoogleCodeExporter]

> I could, I have to ask to the administrator, to set the sticky bit
> for /opt/appli, but surely not for /opt.  I will test it.

Only the world-writable directories need to have the sticky bit set.

> The compilation flag seems a good solution
> --without-path-permission-check What are the risks of that?

If I decided to add that flag I was going to have it ignore all path
permissions checks. This would mean that an insecure installation
of pdsh wouldn't be detected and pdsh may load a trojan or otherwise
malicious module. The risk would be you would inadvertently be
running attacker's code. If you ever ran pdsh as root it would
mean that your system would be compromised. (But if you could run
as root you could just fix the permissions)

> Another question.  Trying the installation I installed pdsh on my
> home on two different cluster (and 2 different home).  In the first
> psdh works fine but the executables have root ownership In the second
> the owner of the executables is me but pdsh doesn't work.  Any idea?
>

I'm not sure, I would have to see the errors.

Original comment by mark.gro...@gmail.com on 6 Apr 2011 at 1:05

[GoogleCodeExporter]

> I resolved my problem by modifying the source pdsh/src/mod.c
> I commented the control on permission:
> from line 888 to 892
> from line 981 to 988
> from line 1062 to 1070
> and changing the ownership of the executable with the installing user one.
> What do you thin about it?

It is much easier to tell what you've done if you generate a patch.
i.e.

 cp mod.c mod.c.orig
 <edit mod.c>
 diff -up mod.c.orig mod.c > patch

Then attach the patch to this issue.

However, it sounds like you just disabled the path permissions checks, which
is what the build-time flag was going to do anyway. So it is fine, but use
at your own risk. ;-)

mark

Original comment by mark.gro...@gmail.com on 6 Apr 2011 at 1:08

[GoogleCodeExporter]

Hello,
thanks for your explaination.
here my patch

Original comment by man74...@gmail.com on 6 Apr 2011 at 1:23

Attachments:

• patch

[GoogleCodeExporter]

Your patch is functionally ok, but it is better to just comment out the call
to _path_permissions_ok(). There is no need to walk the directory tree if we
aren't checking its perms.

Original comment by mark.gro...@gmail.com on 6 Apr 2011 at 1:50

Attachments:

• no-path-permssions-check.patch

[GoogleCodeExporter]

thanks a lot.
your application works very pretty
Regards,
Marco

Original comment by man74...@gmail.com on 6 Apr 2011 at 4:26