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

What are the permissions on the files instmodsh and perldoc?

Have you tried $ perl -S instmodsh or $ perl -S perldoc?

When you get perldoc working try 


$ perldoc -l strict
C:\perl\5.10.1\lib\strict.pm

$ perldoc -l HTML::Template
C:\perl\site\5.10.1\lib\HTML\Template.pm

$ perldoc -l Bundle::CPAN
No documentation found for "Bundle::CPAN".

$ which instmodsh
C:/perl/5.10.1/bin/instmodsh

$ perldoc -l instmodsh
C:\perl\5.10.1\bin\instmodsh

[download]
Alternatively 
$ perl -Mstrict -le " print for values %INC"
C:/perl/5.10.1/lib/strict.pm

[download]

Replies are listed 'Best First'.
Re^4: /usr/bin/instmodsh: Permission denied.
by rnaeye (Friar) on May 23, 2010 at 16:21 UTC

    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!

[reply]
[d/l]
[select]

      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]
      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]

In Section Seekers of Perl Wisdom