-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Wrong permissions on system-wide installed gem files #2136
Comments
Is the only way to normalize the permissions on the files to run chmod? Because we used to do that, and disabled it because someone else filed a bug about us not respecting the system umask. |
Do you have a reference to the other ticket? Can't seem to find that. |
I've never used install(1) before, and neither Bundler nor Rubygems use it, so I'm not sure how that's relevant to this particular issue. When I said "system umask" I actually meant the user's umask. Bundler originally normalized permissions, someone filed a bug that we should respect the current umask, and now we do. Why should we stop respecting the umask? Bundler installing to "system" gems does not actually mean it is installing gems that are available to the entire system, that's up to the system's administrator. It just means that Bundler is installing gems to the GEM_HOME directory, rather than a directory isolated to the single Gemfile being installed. |
Actually, I do not care so much about the umask, but about files ending up in root-owned directories that are user-writeable. If I'm not missing something, the system administrator can not easily change this. - And, this should be easy to fix with s/mv/cp/. Regarding install(1), I just noticed that Ruby itself actually uses tools/rbinstall.rb, and Ruby itself forces 0644/0755 on the files it installs. I'm not asking you to override the user's umask if Bundler writes to user-owned directories; but the very moment Bundler writes to directories owned by root (especially if these are the default Rubygems directories), the calling user's umask has no place in determining file permissions any more. (Note that Bundler starts sudo here; it leaves the security domain of the calling user, so the calling users settings should not apply.) If you say that the umask problem is a Rubygems problem, then I agree that you should not try to fix it and I'll see that the original Debian bug will get reassigned to Ruby(gems). |
@indirect any reason not to use |
|
Other issues that reference this problem: rubygems/rubygems#560 rubygems/rubygems#191 |
@rbeede so now that you've conclusively demonstrated that this issue is in Rubygems and not in Bundler... should I close this? |
Would it be feasible to have Bundler provide some type of warning about file ownership and permissions if it detects it is writing into a directory owned by root? Perhaps something along the lines of: "WARNING: Files were written to which may be a system-wide library location (owned by root), but the permission mode applied was <####> which is [not accessible to everyone | writable by anyone]. Please verify this is what you intended and if not manually correct the permissions yourself." |
A warning along those lines seems reasonable. |
Bundler still honors Rubygems' permissions as set, but now sets its own permissions on any files created by it to |
It would be nice if a warning like the one mentioned by @rbeede was implemented. It seems rubygems emits a warning at gem build time, but you never get to see it when installing with bundler. I just installed some gems with bundler (1.3.5) with a umask of 066 and got the following traceback for my trouble, which is not very user-friendly:
1.3.5 is admittedly pretty old now, but looking through the changelog, I see no mention of any such warning having been implemented in later versions so I don't believe that to matter in this instance. |
I'd be happy to accept a pull request for such a warning, but please try using a version of Bundler that is less than two years old, first. |
As of what Bundler version? |
When using bundler as non-root, gem files installed into the system location can end up with the wrong permissions, when the user running bundler has a umask != 022.
Additionally, gem cache files end up being owned by the user running bundler.
Example for the cache file ownership:
Looking at the code, lib/bundler/fetcher.rb does a sudo mv of the cache file into it's final location; replacing this with cp should make this part of the issue go away.
The other part is that the files of the gem themselves end up being created with the users umask.
Example (from the original reporter) with umask 027:
(Other users won't be able to read these gems.)
I'd have expected all the gem files to be owned by root, and have normalized permissions of 0644 / 0755 respectively.
This issue was reported by a user of the Debian package for bundler [1], but I have reproduced this with bundler 1.2.1 installed with gem install.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691743
(Edited twice because I failed to understand the entirety of the issue at first.)
The text was updated successfully, but these errors were encountered: