Opened 4 years ago

Closed 3 years ago

Last modified 12 months ago

#8248 closed bug (wontfix)

GHCi should not fail to honour ghci.conf or .ghci if group writable

Reported by: afcowie Owned by: whisky
Priority: normal Milestone: 7.10.2
Component: GHCi Version: 7.6.3
Keywords: Cc: hvr, mboes
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: #9324 Differential Rev(s): Phab:D805
Wiki Page:

Description

Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of

-rw-r--r--.  1 andrew users    19 Sep  5 08:29 ghci.conf

as us old traditionalists would have it, you get

-rw-rw-r--.  1 andrew andrew   19 Sep  5 08:29 ghci.conf

because the umask in such cases is 0002 instead of 0022.

There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros.

GHC, however, is being a bit silly in emitting the following:

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
*** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING!
Prelude> 

Foremost the fact that the file is group writable is not a problem and the user's choice, particularly in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't .ssh/.

Can this check and attendant behaviour be removed?

AfC

Change History (15)

comment:1 Changed 4 years ago by afcowie

Summary: GHCi should not warn if group writableGHCi should not fail to honour ghci.conf or .ghci if group writable

comment:2 Changed 3 years ago by thomie

Cc: hvr added

Previous discussion: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/1690 https://www.haskell.org/pipermail/haskell-cafe/2010-December/087078.html

I'm not sure what to do. You mention "when a new user is created there is also simultaneously a group created with the same name". Isn't it possible for other users to also be a member of that group (and even that the user owner isn't: user andrew doesn't need to be a member of group andrew)?

Note: file permissions of ~/.pythonrc.py are not checked at all.

comment:3 Changed 3 years ago by thomie

Cc: mboes added

cc mboes, since he was the last one to touch this code, and maybe has an opinion.

comment:4 Changed 3 years ago by hvr

IMHO, .ghci is comparable to .bash_profile/.bashrc et al, in that it allows code to be injected if not properly protected against users.

Otoh, maybe we could define a magic comment to be placed at the start of .ghci to disregard this protection. E.g. something simple as

-- insecure
:set ...
:def ...

comment:5 Changed 3 years ago by mboes

This check used to make GHCi way too fussy, but I'm quite happy with the current compromise (check is ignored when providing -ghci-script explicitly, or when user is root). Perhaps just improve the warning message to explain to the user exactly what is making GHCi unhappy and how to fix it? A umask of 002 only affects the default permissions, but it's easy enough for the user to chmod to something known to be safe.

comment:6 Changed 3 years ago by thomie

Perhaps just improve the warning message to explain to the user exactly what is making GHCi unhappy and how to fix it?

Improving the current warning is certainly a good idea.

For a discussion to make reading of .ghci files even stricter, see #6017.

comment:7 Changed 3 years ago by thomie

Keywords: newcomer added

comment:8 Changed 3 years ago by whisky

I'm taking a look at this bug. Would it suffice to include a comment to chmod 644 the .ghci file? I've tested it out and it works fine on my local machine after running the command.

comment:9 Changed 3 years ago by whisky

Owner: set to whisky

comment:10 in reply to:  8 Changed 3 years ago by thomie

Differential Rev(s): Phab:D805
Milestone: 7.12.1
Status: newpatch

comment:11 Changed 3 years ago by afcowie

Of course the user can use chmod.

The point is they shouldn't have to.

If they (or their distro) chooses to make the file group writable, it's not an increased attack surface. You're just screwing the user.

AfC

comment:12 Changed 3 years ago by Thomas Miedema <thomasmiedema@…>

In b972de0365f94e1be9d78537152eee969dc5f4cb/ghc:

Suggest how to fix .ghci when it is group writeable (#8248)

```
chmod 664 $PATH_TO_GHCI_CONF/.ghci
```

Run ghci. You will now get a warning + a suggestion:

```
  *** WARNING: $PATH_TO_GHCI_CONF/.ghci is writable by someone else, IGNORING!
  Suggested fix: execute 'chmod 644 $PATH_TO_GHCI_CONF/.ghci'
```

Execute fix and the warning should disappear.

Reviewed By: mboes, thomie

Differential Revision: https://phabricator.haskell.org/D805

comment:13 Changed 3 years ago by thomie

Keywords: newcomer removed
Resolution: wontfix
Status: patchclosed

afcowie: I don't think there is a consensus to remove the current check. Please use #6017 for further discussion.

For reference, this feature was introduced 14 years ago, in commit dfbbfedc7e68d3095a37e4359b69eccc27e5398c:

Author: simonmar <unknown>
Date:   Fri May 4 14:56:53 2001 +0000

    [project @ 2001-05-04 14:56:53 by simonmar]
    - only read ~/.ghci if it is owned by the current user and isn't
      writable by anyone else.
    
    - Only read ./.ghci if both . and ./.ghci are owned by the current
      user and aren't writable by anyone else.  I think this is
      sufficient: we don't need to check .. and ../.. etc. because "."
      always refers to the same directory while a process is running.
...

comment:14 Changed 3 years ago by thoughtpolice

Milestone: 7.12.17.10.2

I went ahead and picked this into the ghc-7.10 branch; see 53f723589819f5e232d2333a993a4d0341702dc4.

comment:15 Changed 12 months ago by anohigisavay

I just got hit by this issue.

I have been using ACL for more granular permission control. I created two users to access different desktop environments to avoid certain conflict issues, while essentially they are the same user and should be able to access each other's home directory without any problem. When ACL is enabled the group permission bits in the traditional UGO mechanism act as the mask for ACL (i.e. the maximum available permission for ACL_USER, ACL_GROUP_OBJ and ACL_GROUP). Thus it must be set to rw- instead of r--.

This limitation renders ACL ineffective for the home directory.

While it is obviously overkilling for GHCi to consider all these security enhancement mechanisms (SELinux and others also exist), I suggest we can leave the choice between security and flexibility to the users.

Note: See TracTickets for help on using tickets.