Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^4: /usr/bin/instmodsh: Permission denied.

by rnaeye (Pilgrim)
on May 23, 2010 at 16:21 UTC ( #841262=note: print w/ replies, xml ) Need Help??


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

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

Now, it works!


Comment on Re^4: /usr/bin/instmodsh: Permission denied.
Select or Download Code
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
      s/unpossible/unlikely/

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

      --MidLifeXis

        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.

        cd /usr/bin ln -fs foo myproggie ... cd /tmpdirMISSPELL/ rm *

        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

Re^5: /usr/bin/instmodsh: Permission denied.
by MidLifeXis (Prior) 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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://841262]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2014-09-21 11:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (168 votes), past polls