Incorrect permissions on library install #85

Closed
bos opened this Issue May 24, 2012 · 8 comments

Comments

Projects
None yet
2 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #93, reported by guest on 2006-09-22)

My user umask is 0007 and my root umask is 0022. When I build a library with cabal and then install with:

# sudo runghc Setup.hs install

The library which is installed doesn't have the correct permissions for cabal to be able to reference it later when I build other things.

My work around is to follow the install with the following command:

# sudo chmod -R a+rX /path/to/new/library

This happens on all versions of cabal that I have tried.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2006-09-22)

Isaac suggested a fix:

So we could use the current permissions in the tree (which we attempt to set correctly for executables). If the setup file changes them, so be it. We set the owner as the installer, and if it's --user, leave it at that, if it's --global, project the user permissions for group and global. (If root is installing it, we change the owner to root so projecting user permissions will then work).

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2006-10-20)

This is actually quite hard because we have no way in Haskell of portably setting the permissions bits for user/group/other.

We could do it perhaps if we used cpp and used functions from the posix lib.

I'm punting from the immediate milestone.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-03-12)

See #454.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-01-19)

Fixed in cabal head and the 1.6 branch.

The behavior now when installing is that we ignore the permissions the files had in the build tree and the user's umask. We explicitly set permissions for all files we install.

The only inconsistency is that we're not yet setting the permissions of directories we create when installing. So they currently inherit the umask of the installing user. In the case in this bug that will work fine.

Contributor

bos commented May 24, 2012

(Imported comment by GregoryWeber on 2009-01-30)

Replying to @dcoutts:

Fixed in cabal head and the 1.6 branch. The behavior now when installing is that we ignore the permissions the files had in the build tree and the user's umask. We explicitly set permissions for all files we install.

That seems to be working well for most files, but those listed in the data-files field of the Cabal package are still installed with permission rw for the owner (root), zero permission for group and others.

[root@squirrel cal3d-examples-0.1]# uname -a
Linux squirrel.localdomain 2.6.27.25-170.2.72.fc10.i686 #1 SMP Sun Jun 21 19:03:24 EDT 2009 i686 i686 i386 GNU/Linux
[root@squirrel cal3d-examples-0.1]# ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
[root@squirrel cal3d-examples-0.1]# ghc-pkg list Cabal
/usr/lib/ghc-6.10.1/./package.conf:
    Cabal-1.6.0.1
[root@squirrel cal3d-examples-0.1]# runghc Setup install
Installing executable(s) in /opt/bin
[root@squirrel cal3d-examples-0.1]# cd /opt/share/cal3d-examples-0.1/
[root@squirrel cal3d-examples-0.1]# ls -l
total 4
drwxr-xr-x 2 root root 4096 2009-06-27 17:13 data
[root@squirrel cal3d-examples-0.1]# ls -l data
total 696
-rw------- 1 root root   6400 2009-06-27 17:13 cally_calf_left.cmf
-rw------- 1 root root   6464 2009-06-27 17:13 cally_calf_right.cmf
-rw------- 1 root root  16968 2009-06-27 17:13 cally_chest.cmf
-rw------- 1 root root    210 2009-06-27 17:13 cally_chest.xrf
-rw------- 1 root root   3216 2009-06-27 17:13 cally.csf
[snip]
I can work around this by doing
chmod -Rf g+rX,o+rX .
in the source directory where I am developing the package, before building the source tarballs for release. Of course, likewise the installer can do so after unpacking the tarballs, or even after the files are installed.

Seems like this might be a big nuisance for projects using darcs with multiple developers, since darcs does not preserve file permissions.

Contributor

bos commented May 24, 2012

(Imported comment by svat2 on 2009-06-27)

This bug still exists, it is not restricted to library installs or to Unix, and is a big nuisance.

My OS is Mac OS X, user umask is 077, cabal version is "cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library". I set my cabal to global installs, and did sudo cabal install pandoc. A lot of files (including the binary itself) were installed with incorrect permisssions, so I (as user) couldn't run the program. I tried changing umask and reinstalling with sudo cabal --reinstall install pandoc, but it didn't fix permissions. (Possibly because my root umask also appears to be 077 for some reason.)

Doing sudo chmod -vR a+rX /usr/local was the workaround that finally helped.

Contributor

bos commented May 24, 2012

(Imported comment by guest on 2010-04-23)

It hasn't been mentioned that this actually causes a system-level problem on
GNU/Linux which potentially makes it more severe: it makes the mandb cron
task at least complain and, I think, actually fail after getting

  /usr/bin/mandb: can't open /usr/local/share/man/man1/markdown2pdf.1: Permission denied
following a `cabal install --global pandoc', although the binary is installed

appropriately. This is with

  cabal-install version 0.8.2
  using version 1.8.0.6 of the Cabal library
-- d.love(haskell) @ liv.ac.uk
Owner

tibbe commented Jan 28, 2013

3 years old and applies to an old cabal, so I'm optimistically closing this. Feel free to create a new bug (With repro instructions) if the bug resurfaces.

tibbe closed this Jan 28, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment