Changes between Initial Version and Version 1 of Ticket #13579, comment 51


Ignore:
Timestamp:
10/12/12 16:52:41 (9 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13579, comment 51

    initial v1  
    1 Case (B): (current dir group writeable) - It's perfectly safe to make directories group writeable, provided the group is sufficiently restricted. In fact, it's a very conceivable setup if you have multiple administrators that you want to give a lot of latitude, short of root (e.g., because your filesystem is NFS with root-squash)
     1Case (B): (script dir group writeable) - It's perfectly safe to make directories group writeable, provided the group is sufficiently restricted. In fact, it's a very conceivable setup if you have multiple administrators that you want to give a lot of latitude, short of root (e.g., because your filesystem is NFS with root-squash)
    22
    3 Case (C): (current dir only user writable but by different UID): That's how I install packages like sage! Because they need frequent updates, they're not owned by root but by a dedicated maintenance account.
     3Case (C): (script dir only user writable but by different UID): That's how I install packages like sage! Because they need frequent updates, they're not owned by root but by a dedicated maintenance account.
     4
     5In fact, if the dir is `go-w` and owned by a different UID, the script is very likely also owned by a different UID. The security risk really isn't in the imports in that case (if there is any at all)
    46
    57None of these affect correct functioning of sage with the patch, since the required paths are explicitly added to sys.path, but it does illustrate that your detection heuristics are not very accurate.
    68
    7 As pointed out before, even `o+w` isn't necessarily a security risk, but since `/tmp` likely is, I'd find that an acceptable compromise. The other cases are harder to work around if they bite you.
     9As pointed out before, even `o+w` isn't necessarily a security risk, but since `/tmp` likely is, I'd find that an acceptable compromise. The other cases are harder to work around if they bite you. Really, the import behaviour only causes additional security risks on directories writeable by untrusted people ''and the sticky bit set''. Otherwise, you can't trust the script you're running in the first place! Would it be possible to only do these checks in the presence of a sticky bit?