1

I use Python on Linux and OS X, and I'm trying to think of a good reason not to chmod my Python site-packages directory to 777. It seems like that is better to do than sudoing every time I want to make the slightest modification. Or have I gone crazy? Note that this is primarily for my development machines and not any kind of production servers.

Disclaimer: Yes, I know the caveats. It's bad to pip install or easy_install things that are provided by a package manager. And it's better to use a virtualenv than modify the global Python installation in most cases.

2 Answers 2

3

If that's your machine then you may as well do whatever suits you. My main reason for leaving permissions like they are is that it means I'm less likely to destroy something by accident.

It's really down to what level of responsibility you want to take, if it's your own box and you're happy that you won't run malware and won't trash anything by accident there's no decent reason not to.

The only other concern I'd have is that if I were developing a package and wanted to test it and its deployment in real life conditions I wouldn't be able to since everything's writable.

I do know some security experts who'd disagree, but ultimately security should be balanced with usability. At one talk I was at a security guy was insisting that the operating system should be changed to simply not allow users to do certain things. Luckily at that point someone piped up with 'I'm sorry Dave, I can't let you do that'...

2
  • 1
    My concern is that setting everything to 777 could lead to goofy things down the road due to installer and permission fix assumptions, and altering them can create troubleshooting issues on my own machine...altering permissions can be a nightmare to move back to a known-good state unless the built-in repair permissions will fix it. Jan 29, 2010 at 13:49
  • I agree. I'd have similar worries and that's the another reason that I haven't done it myself. Jan 30, 2010 at 15:57
1

It's not really a good idea. 777 means any user can write modules, including, say, a web server user being controlled by a compromised webapp script. If that user can write a py or pyc to site-packages which then gets imported by another user such as root, your low-privilege compromise is escalated to a serious machine-level compromise. If you're so sure that your machine is safe from all attack that this is acceptable, fine... but if that's the case then you might as well just be running everything as root really!

Better: if you want modules that only your user has access to and can update without having to sudo, add a user-specific module path. You can do this with PYTHONPATH or by modifying sys.path, but from Python 2.6 that isn't necessary as you get one by default, ~/.local/lib/python2.6/site-packages. See PEP 370 for details.

1
  • I've tried going the local packages route before, but it ended up causing too much confusion as far as what package was installed where. If I want to isolate things, I'll just use a virtualenv instead. Jan 29, 2010 at 18:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .