User private groups are not an abnormal configuration, but GHCi has such strict security that they are not allowed! :; ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done.Loading package integer ... linking ... done.Loading package base ... linking ... done. *** WARNING: /Users/jsn/tmp is writable by someone else, IGNORING! *** WARNING: /Users/jsn/tmp/.ghci is writable by someone else, IGNORING! Prelude> :q Leaving GHCi. :; cd ../ :; ls -laR tmp/ tmp/: total 4 drwxrwx--- 2 jsn jsn 102 2008-12-02 10:19 . drwxr-x--- 49 jsn jsn 2890 2008-12-02 10:17 .. -rw-rw---- 1 jsn jsn 159 2008-12-02 10:20 .ghci I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same. It would be preferable, however, to do away with the restriction altogether. -- _jsn
On Tue, 2008-12-02 at 10:25 -0800, Jason Dusek wrote:
I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same.
Hmm. That's a convention but it doesn't have any particular semantics in unix security. If it really is only you in that group then why does it need to be group writable? Isn't that the simple workaround?
It would be preferable, however, to do away with the restriction altogether.
I'm not sure they can do away with it completely. The problem of course is that some other user could drop a .ghci file and run arbitrary IO actions as you. Duncan
Duncan Coutts
Jason Dusek wrote:
I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same.
Hmm. That's a convention but it doesn't have any particular semantics in unix security.
It is a common convention, of great practical value. Unfortunately, UNIX security is very much a matter of conventions.
If it really is only you in that group then why does it need to be group writable? Isn't that the simple workaround?
It is not abnormal to have a umask of 00x when using user private groups, the idea being, when you are actually in a public folder with public ownership, the permissions will be set correctly for collaborators. With this umask, all temporary '.ghci' files are created with permissions that are incompatible with GHCi.
I'm not sure they can do away with it completely. The problem of course is that some other user could drop a .ghci file and run arbitrary IO actions as you.
I appreciate that, in the general case, a malicious person could place '.ghci' files in random places all over the filesystem, hoping someone will be so unlucky as to start a GHCi session there. User private groups do provide a way to avert this danger -- check that the only member of the owning group is the active user -- so there is no need to worry in that specific case. (Or is there? I will think about it for a spell, but I am pretty sure.) -- _jsn
participants (2)
-
Duncan Coutts -
Jason Dusek