gmane.comp.lang.haskell.glasgow.user

Jason Dusek | 2 Dec 19:22

ghci and user private groups

  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

(Continue reading)

headers

Duncan Coutts | 3 Dec 00:39

Re: ghci and user private groups

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

headers

Jason Dusek | 3 Dec 07:46

Re: ghci and user private groups

Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> wrote:
> 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

(Continue reading)