Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pdftk cask messes up permissions on /usr/local #7707

Closed
albcorp opened this issue Nov 30, 2014 · 23 comments · Fixed by #7761
Closed

pdftk cask messes up permissions on /usr/local #7707

albcorp opened this issue Nov 30, 2014 · 23 comments · Fixed by #7761

Comments

@albcorp
Copy link

albcorp commented Nov 30, 2014

After running

brew cask install pdftk

the group ownership of '/usr/local' changes from 'admin' to 'wheel', and the group write bit is removed.

This is a very serious bug, because it causes the next run of brew update to fail in weird and wonderful ways. The workaround is to recursively set the ownership and group write permission on '/usr/local' and run the brew cleanup commands suggested by brew doctor

sudo chown -R root:admin /usr/local
sudo chmod -R g+wX /usr/local
cd /usr/local/Library
git stash
git clean -d -f

After that Homebrew can be safely updated

regards

Andrew

@vitorgalvao
Copy link
Member

We’ll have to look into it, but first, what is the result if you install the package manually? We’re not doing anything special with this cask to warrant that change, so it might be pdftk’s installer doing the change, and we need to rule that out first.

@vitorgalvao vitorgalvao added the awaiting maintainer feedback Issue needs response from a maintainer. label Dec 1, 2014
@albcorp
Copy link
Author

albcorp commented Dec 1, 2014

Thanks for your prompt reply.

I can confirm that using the pdftk installer downloaded from the following
link causes the same problem.

https://code.google.com/p/flexpaper-desktop-publisher/downloads/detail?name=pdftk-1.44-osx10.6.dmg&can=2&q=

Perhaps the cask could include some instructions to repair the permissions

On 1 December 2014 at 15:15, Vítor Galvão [email protected] wrote:

We’ll have to look into it, but first, what is the result if you install
the package manually? We’re not doing anything special with this cask to
warrant that change, so it might be pdftk’s installer doing the change, and
we need to rule that out, first.


Reply to this email directly or view it on GitHub
#7707 (comment)
.

Andrew Burrow
Twitter @albcorp
Blog (coming soon) albcorpus.net

@rolandwalker
Copy link
Contributor

Thanks for the report. Even though this is an upstream bug, we should address it.

My problem with doing a chown -R is that this makes us just as bad as pdftk. There are users who have other user/group settings in /usr/local, including heterogeneous ownerships throughout the tree. We shouldn't override this. In addition, some users have Homebrew in a different directory than /usr/local/. We should unpack the pdftk pkg file and see if it is possible to reverse the damage more delicately.

Although, it might be quite a pain to try to capture the existing ownership for multiple files and restore the state. We don't have any equipment for that.

A better answer might be to implement a :recursive_xar container type, which lets us unpack and manipulate these contents as an ordinary archive, without running the bad postflight script within.

In the meantime, I'd be inclined to remove the Cask. We instituted the homebrew-boneyard repo to make deletion less permanent. Any interested person could continue to work on the Cask over there.

@vitorgalvao vitorgalvao removed the awaiting maintainer feedback Issue needs response from a maintainer. label Dec 1, 2014
@tapeinosyne
Copy link
Contributor

In the meantime, I'd be inclined to remove the Cask.

Most definitely.

@vitorgalvao
Copy link
Member

Weird, I thought I had replied as well, when removing the label. I agree with you both.

@albcorp Would you care to contact the developer about the issue?

@albcorp
Copy link
Author

albcorp commented Dec 1, 2014

The pdftk installer appears to explicitly set permissions on its own files
and a chain of ancestor directories. Hence, /usr/local but not all
subdirectories of /usr/local.

Vítor, I will contact the developer/packager of pdftk, and explain that it
is aggressively setting ownership and permissions in a way that breaks
other systems

On 2 December 2014 at 04:45, Vítor Galvão [email protected] wrote:

Weird, I thought I had replied as well, when removing the label. I agree
with you both.

@albcorp https://github.com/albcorp Would you care to contact the
developer about the issue?


Reply to this email directly or view it on GitHub
#7707 (comment)
.

Andrew Burrow
Twitter @albcorp
Blog (coming soon) albcorpus.net

rolandwalker added a commit to rolandwalker/homebrew-cask that referenced this issue Dec 3, 2014
pending solution for mangling permissions on /usr/local

closes Homebrew#7707
@tapeinosyne
Copy link
Contributor

Thanks for taking the time to contact the vendor, it is much appreciated. In the interim, we have moved the cask to caskroom/boneyard.

@rolandwalker, should we keep the issue open as a reminder?

@rolandwalker
Copy link
Contributor

Good idea.

@jvenator
Copy link

@albcorp did you ever get a response from the PDFtk developer?

And perhaps not the right place to discuss it, but in the absence of the brew-cask option did you find an install process that avoided these permissions issues altogether? I had a bunch of user permissions issues on a machine machine recently that included the 'wheel', and I'm now thinking this may have been the culprit.

@michelschinz
Copy link

@jvenator Personally I installed pdftk by hand, by doing roughly the following:

  1. I downloaded the .pkg from pdftk's web site,
  2. I manually extracted its contents, using xar (first level) and cpio (second level),
  3. I created a directory in /usr/local/Cellar called pdftk and then a sub-directory for the version (2.02 in my case), in which I put the various files where Homebrew expects them,
  4. I ran brew link to create links from /usr/local/... to the various files (e.g. the pdftk binary) I had just copied.

Here is what I now get when I run brew list pdftk:

/usr/local/Cellar/pdftk/2.02/bin/pdftk
/usr/local/Cellar/pdftk/2.02/lib/libgcc_s.1.dylib
/usr/local/Cellar/pdftk/2.02/lib/libgcj.11.dylib
/usr/local/Cellar/pdftk/2.02/lib/libiconv.2.dylib
/usr/local/Cellar/pdftk/2.02/lib/libstdc++.6.dylib
/usr/local/Cellar/pdftk/2.02/share/man/man1/pdftk.1

There's some work involved, but I think it's the easiest solution given the current problems.

@caffeineflo
Copy link

@michelschinz Your solution looks good, I would love to see a homebrew working like this as I heavily rely on pdftk in some of my CI routines.

@jawshooah
Copy link
Contributor

@evils Working on it.

@jvenator
Copy link

Having never gone through process of manually installing and breaking apart a .pkg app, I ran into some noob bumps along the way attempting to follow the recommended approach above. So I put together a thorough list of exact steps and dropped them into a public gist. Thanks for the initial help @michelschinz!

Installing PDFtk Server edittion on your Mac

@vitorgalvao
Copy link
Member

@jvenator Fenced code blocks could help keep the gist more organised, as opposed to having a bunch of commands on the same line, some with &&, some not (and why are some between parenthesis?).

Commenting here because Github does not warn on Gist comments.

@jvenator
Copy link

@vitorgalvao thanks, fixed. The parenthesis were to maintain the current directory prior to the command, which I thought was helpful initially (found in this cpio question). However, it ended up not mattering the way everything was written.

As far as breaking out the larger && commands into their individual single commands, it was to provide clarity around what was actually being done. As a novice in many areas myself, I often piggyback on the work of others, copy/paste, without always understanding what's going on. I always appreciate when someone takes the time to explicitly breakout what's taking place.

@vitorgalvao
Copy link
Member

I actually meant that instead of doing

mkdir /usr/local/Cellar/pdftk mkdir /usr/local/Cellar/pdftk/2.02

or

mkdir /usr/local/Cellar/pdftk
mkdir /usr/local/Cellar/pdftk/2.02

or even

mkdir /usr/local/Cellar/pdftk && mkdir /usr/local/Cellar/pdftk/2.02

you could do

mkdir /usr/local/Cellar/pdftk
mkdir /usr/local/Cellar/pdftk/2.02

which is clearer and still allows users to copy and paste all the commands without a hitch.

@caffeineflo
Copy link

@jvenator Is this becoming a brew cask formula in the future?

@jvenator
Copy link

jvenator commented Feb 3, 2015

@vitorgalvao thanks for the feedback. I was trying to offer both the ease of copy/paste of the grouped commands along with the explicitness of breaking them out individually.

@evils unfortunately not by me. I didn't even know what brew cask was until I needed to install PDFtk :-/ For my own practice I might make it a local script, but that's the extent of my abilities/plans at present.

@vitorgalvao vitorgalvao added the upstream Issue which needs to be resolved by the upstream project. label Mar 15, 2015
@vitorgalvao
Copy link
Member

@albcorp Any luck contacting the developer?

@rusterholz
Copy link

+1 for finding a permanent solution to this.

This was referenced May 24, 2015
@100ideas
Copy link

@michelschinz's technique above of unpacking the official installer and copying the files into the cellar manually worked for me.

How unpack and pack pkg file? helped me figure out how to unpack the cpio.gz archive of the pdftk package.

I got pdftk v.2.02, so moved the relevant files to /usr/local/Cellar/pdftk/2.02/bin/pdftk etc.

Then brew switch pdftk 2.02 to link it.

Just what worked for me in case anyone else wants to try this route.

@vitorgalvao
Copy link
Member

Closing in favour of #11351, where the developer is being contacted.

@gaming-hacker
Copy link

i just extracted the contents of the file and moved to where i wanted. i almost never let a pkg install.

@miccal miccal removed the upstream Issue which needs to be resolved by the upstream project. label Dec 23, 2016
@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.