Hide Forgot
Description of problem: The report_version() function in gitolite.pm requires a file conf/VERSION. Version-Release number of selected component (if applicable): gitolite-2.2.1-1.fc17 How reproducible: $ssh gitolite@<server> info ***** ABORTING ***** open /usr/share/gitolite/conf/VERSION failed: directory or file does not exist at /usr/lib/perl5/vendor_perl/gitolite.pm line 125 Steps to Reproduce: 1. install gitolite 2. perform steps per README-fedora 3. try to get the access information Actual results: ***** ABORTING ***** open /usr/share/gitolite/conf/VERSION failed: directory or file does not exist at /usr/lib/perl5/vendor_perl/gitolite.pm line 125 Expected results: hello reporter, this is gitolite 2.2.1-1.fc17 running on git 1.7.8.3-1.f17 the gitolite config gives you the following access: R W gitolite-admin @R_ @W_ testing Connection to <server> closed. Additional info: The required change in the gitolite-2.0-rpm.patch was lost in the first 2.2 package release. Also notice that the line 598 of gitoline.pm: print "\rthe gitolite config gives you the following access:\r\n"; is missing the "\n" control character and it overwrites the previous line in the screen output ("hello reporter, ..."). It would be great to report it upstream.
I'm not sure where the VERSION file should come from the Makefile seems to create and then remove it, and it's not present in the upstream tarball. Can you point out what in the patch changed that caused this?
The patch from previous series (gitolite-2.0.3-2.fc16) contained: diff -ur sitaramc-gitolite-4c1e4b2.orig/src/gitolite.pm sitaramc-gitolite-4c1e4b2/src/gitolite.pm --- sitaramc-gitolite-4c1e4b2.orig/src/gitolite.pm 2011-08-08 00:17:56.000000000 -0400 +++ sitaramc-gitolite-4c1e4b2/src/gitolite.pm 2011-08-08 14:10:35.330500567 -0400 @@ -493,7 +493,7 @@ sub report_version { my($user) = @_; print "hello $user, the gitolite version here is "; - print slurp( ($GL_PACKAGE_CONF || "$GL_ADMINDIR/conf") . "/VERSION" ); + system("rpm", "-q", "--qf", '%{version}-%{release}', 'gitolite'); } sub perm_code { You can patch current code similarly, add a VERSION file created when cloning the source tree for packaging, or generate it at the build time like: echo "%{version}-%{release}" >conf/VERSION
Since we already patch to get the version from RPM, I'll just comment that out.
Hi, I would seriously suggest finding better solutions than calling rpm, if only because this completely breaks under SELinux (and is a bad practice generally).
I agree that calling rpm isn't ideal, but it seems to work on my selinux-enabled f16 box. What does it do on yours?
It probably only works because gitolite user is set up as unconfined_u for you, so it never transitions to the gitosis_t domain. This is the default behaviour, but it's hardly useful, as it executes gitolite as unconfined. Otherwise, the following is returned: ssh gitolite@moppet expand hello mricon, the gitolite version here is Can't exec "rpm": Permission denied at /usr/share/perl5/vendor_perl/gitolite.pm line 496. you have access to the following repos on the server: R W <gitolite> gitolite-admin @R_ @W_ <gitolite> testing
By the way, if you want to test: Create a file called "mygitoliteuser.te" with the following contents: ----CUT---- policy_module(mygitoliteuser, 1.0.0) role mygitoliteuser_r; userdom_restricted_user_template(mygitoliteuser) gitosis_run(mygitoliteuser_t, mygitoliteuser_r) gen_user(mygitoliteuser_u, user, mygitoliteuser_r, s0, s0) ----CUT---- Then run: make -f /usr/share/selinux/devel/Makefile mygitoliteuser.pp semodule -i mygitoliteuser.pp cd /etc/selinux/targeted/contexts/users sed 's/guest_/mygitoliteuser_/g' guest_u > mygitoliteuser_u usermod -Z mygitoliteuser_u gitolite This should set up gitolite to run as a very restricted user with the only permission to transition to the gitosis_t domain (used by gitolite), as opposed to running unconfined.
Beyond the security considerations that Konstantin is bringing up (which are obviously pretty serious), there are 2 additional problems: 1) The "fix" wasn't discussed with the Gitolite author himself, Sitaram is actually quite responsive and if there was a bug upstream he could have fixed it and you wouldn't be maintaining a random patch. Specifically, according to Sitaram, "the verion file gets created -- in a manual (non RPM/DEB) install -- when you run gl-system-install.". If you are assuming this isn't getting run, then the rpm build process 2) Constantly running this rpm command is relatively expensive on a busy server. A text file (which is what's intended) is extremely cheap to read and output, running rpm - not nearly as cheap. It also adds a very messed up dependency on rpm, that quite honest makes no sense. Suggested fix: Instead of using rpm like this (which is an issue on a number of levels) the build process should just create the appropriate file and include it in the rpm.
Logical. I've fixed this in the rawhide update to 2.3.
Thanks, Jon. Could you also put the same solution in the EPEL branches?
Done.
gitolite-2.0.3-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/gitolite-2.0.3-3.el6
gitolite-1.5.9.1-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/gitolite-1.5.9.1-2.el5
Great! Thanks for your help with this.
gitolite-1.5.9.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
gitolite-2.0.3-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.