public/git-daemon options do nothing

[anarcat]

Does the "public" setting of a project affect the way this plugin creates or modifies repositories?

And how about the git-daemon option? What does it actually do?

I have fiddled with the options and couldn't figure it out.

I would expect the "public" setting to set the files to chmod a+rX, and the git-daemon option to drop a git-export-ok file in the repository, it seems it does none of those things.

[kubitron]

Public setting states at least two things:

(1) whether the project will appear to a redmine visitor without them logging in... This is a Redmine feature. (2) Whether or not the git-daemon option matters or not (when a project is not public, then the git-daemon option is ignored).

The git-daemon option, when true (and project is "public"), adds a "daemon" key to the gitolite.conf file for that project. This is a special keyword that causes gitolite to put a "git-daemon-export-ok" flag at the top-level of the repository, thereby flaging to the git-daemon that it is ok for public read-only access. In addition, the combination of a true git-daemon flag and a public project causes the "git://..." syntax to appear in the URL box at the top of the project page.

[anarcat]

Well, I guess what i'm saying here is: it doesn't work. :) I see the "daemon" option in the gitolite config file, but somehow gitolite doesn't add the git-daemon-export-ok file. For example, if i disable the "git-daemon" in a project, gitolite doesn't remove the git-daemon-export-ok file. In fact, it looks like the problem is that the plugin itself doesn't remove the "R = daemon" line from the gitolite config file...

Also, the way permissions are setup right now in gitolite means that I need to run my git-daemon as the gitolite user for it to be able to read the repositories. Unfortunately, it means it can also write them (ouch!). So ideally, those files would be publicly readable if the repository is public. Maybe that's something gitolite should do however.

So I would like to reopen this ticket (but can't ;). Thanks for the followup.

[kubitron]

Ok. Ticket reopened. I can believe that there is a bug in this feature, since I don't use it. The 'daemon' key should be removed. I'll look into it.

As for the permissions of the gitolite daemon, I don't really know what to suggest. Can you not restrict it via configuration to only only allow read-only access?

[anarcat]

I think that the default configuration is read-only, but i prefer, from a security standpoint, to not have to trust the code in the git-daemon....

Since redmine has sudo on the gitolite user, can't it just change the permissions (with chmod -R) on the repository when the public status changes?

[kubitron]

I don't believe so, since gitolite needs to write the repository when changes are pushed through the ssh and httpd interfaces. I would not want to interfere with that process...

If you are worried about security, why not just avoid the git-daemon interface?

[anarcat]

It's fine that gitolite has write access, I am just talking about giving and removing "world read" (chmod -R o+rX) permissions to the repository.

git-daemon is essential to give anonymous users read (not write!) access to the repository. I trust git-daemon, but security by layers apply: for example, it's not because i trust my webserver that I give it access to the files it's serving.

[anarcat]

I did my homeworks and looked at the gitolite documentation, and there's a umask setting I can change, so nevermind the chmod issues, sorry! :)

See http://sitaramc.github.com/gitolite/rc.html

However, the underlying problem with git-daemon-export-ok still remains: the R = daemon line isn't removed.

[kubitron]

Ok. Try the testing branch. This should work correctly.

[anarcat]

I confirm this works.

[kubitron]

This fix now moved to master branch.