in reply to Re^3: /usr/bin/instmodsh: Permission denied.
in thread /usr/bin/instmodsh: Permission denied.

Thank you everyone. Someone from apple.com>Unix forum solved my problem. I needed to change the file permissions as below. 

old file permissions:
-rw-rw-rw-  34 root    wheel         807 Jun 24  2009 instmodsh
-rw-rw-rw-  34 root    wheel         807 Jun 24  2009 perldoc

[download]

I set the execute bit using:

sudo chmod +x /usr/bin/instmodsh /usr/bin/perldoc 
new file permissions:
-rwxrwxrwx  34 root    wheel         807 Jun 24  2009 perldoc
-rwxrwxrwx  34 root    wheel         807 Jun 24  2009 instmodsh

[download]

Now, it works!

Replies are listed 'Best First'.
Re^5: /usr/bin/instmodsh: Permission denied.
by MidLifeXis (Monsignor) on May 24, 2010 at 13:30 UTC

    I would recommend auditing your system. The permissions on these files are not sane, and I would not trust that these are the only ones.

    Both the old and the new file permissions are insanely insecure. Whatever set the initial permissions should be sought out summarily executed.

    Unix permissions are grouped into a type indicator, and three groups of three permission "bits".

    • Char 1: type indicator. '-' is a "regular" file, 'd' is a directory, 'l' is a symlink, 'c' is a character special file, 'b' is a block special file, and so on.
    • Char 2-4: Owner ("root" in this case) permissions. Read, Write, Execute.
    • Char 5-7: Group ("wheel" in this case) permissions. Read, Write, Execute.
    • Char 8-10: Other permissions. Read, Write, Execute.

    What do you think happens when Read, Write, and Execute are enabled for other (hint: "other" is able to change the file)? Does a privileged user ever execute that file (hint: if "yes", "other" now has control over what privileged user is executing)?

    The solution given by the mac forum is accurate (that command adds the execute bit to owner, group, and other), but is incomplete. You also need to remove the write permissions from those files. As mentioned above, I would not trust that these are the only files with insecure permissions.

    Update: Removed assumptions about Unix knowledge (added 'hints').

    --MidLifeXis

[reply]
Re^5: /usr/bin/instmodsh: Permission denied.
by Anonymous Monk on May 23, 2010 at 16:35 UTC
    Lol, always check the obvious first. But there is no way Bundle::CPAN changed the permissions on instmodsh/perldoc... thats unpossable
[reply]
      s/unpossible/unlikely/

      Having seen way to many "unpossible" things happen, especially around users, I tend to avoid assigning the impossible attribute.

      --MidLifeXis

[reply]
[d/l]
        cd /usr/bin
ln -fs foo myproggie

...

cd /tmpdirMISSPELL/
rm *

        [download]

        Yes, I have seen code like this. CPAN executes code handed to it by another module's author (with your permission, but still). Impossible is not a word I apply to systems. Period.

        Update: Whoops, replied to myself, not the AM above.

        --MidLifeXis

[reply]
[d/l]
        Having seen way to many "unpossible" things happen, especially around users, I tend to avoid assigning the impossible attribute.

        instmodsh is core program , CPAN won't touch it, so yes, impossible for CPAN to break the permissions, its a user problem.

[reply]

In Section Seekers of Perl Wisdom