todo/lockdown hooksgit-annexhttp://git-annex.branchable.com/todo/lockdown_hooks/git-annexikiwiki2021-06-21T18:12:03Zany chance to avoid necessity to config the hook(s)?http://git-annex.branchable.com/todo/lockdown_hooks/comment_1_649dbc3c951bbabc550e12e87e45b319/yarikoptic2018-02-01T18:54:18Z2018-02-01T18:54:18Z
<p>Thank you Joey for looking into this issue! I am though a bit worried that necessity to configure using some kind of a hook would be ... suboptimal for a number of reasons. Before laying out my argumentation, let me first ask: why alternative "lockdown" mechanisms could not be sensed/configured per each repository during <code>init</code> and implemented within git-annex?</p>
<p>As you have noted <code>git-annex init's probe of the write bit handling fails...</code> so git-annex already checks for a possible way to establish the "lockdown" for a given repository location. It just tries one possible mechanism ATM. But it could as well try multiple ways to achieve it, starting from current "POSIX", and then trying "ACL" if appropriate (i.e. tools found). Then if non-POSIX handling is needed, would simple add yet another configuration to .git/config of that repository, and consult to it to switch to corresponding lockdown implementation <strong>within git-annex</strong>. This would be much more user friendly, and it would allow 3rd party tools using git-annex (such as datalad) to not worry about necessity to configure some additional hooks for a particular location, etc.</p>
comment 2http://git-annex.branchable.com/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7/joey2018-02-05T17:25:20Z2018-02-05T17:04:36Z
<p>Seems likely that there are a couple of different ways to use
ACLs to remove write access. In the simple case, any existing ACL can be
overwritten. In other cases, some other existing ACLs will need to be
preserved and only a single part changed. In some cases, the ACL for a user
should be changed, in others the ACL for a group.</p>
<p>And there are several different varieties of ACLs (POSIX, NFS, Windows).
And there's the immutable bit, which might be wanted in some specific
circumstances but certianly not by most people.</p>
<p>So it makes sense to me to not embed specific knowledge of this into git-annex.</p>
<p>This feels to me like something that the system administrator is going to
want to set up. It would mostly be limited to repositories inside a given
mount point that needs the unusual lockdown method due to using NFS or
whatever. The global gitconfig can be set up to switch on the config only
for those repositories, and the system administrator can set up hooks
for the particular use case.</p>
<p>I don't see why something like datalad would need to worry about this
detail, any more than they worry about the PATH to system programs or other
such things that the administrator sets up.</p>
ACLs keep fighting backhttp://git-annex.branchable.com/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46/yarikoptic2020-06-17T01:18:32Z2019-10-29T18:03:57Z
I am getting back to tackle a datalad/git-annex usecase on one of such (nfs4 ACL) usecases, so if hooks are still the way to go, I will be ready to test <img src="http://git-annex.branchable.com/smileys/smile4.png" alt=";-)" />
comment 4http://git-annex.branchable.com/todo/lockdown_hooks/comment_4_614d2c8c758f9920cd84748f8f0d384e/joey2021-06-21T18:12:03Z2021-06-21T17:41:54Z
<p>There's a choice between the hook needing to replicate git-annex's
use of permissions as well as doing whatever else it does, or git-annex
setting the permissions first, and only then running the hook.</p>
<p>Seems to me that git-annex setting the permissions is better, because then
the hook does not need to worry about details like core.sharedrepository
if it's doing something simple like setting immutable. (But if it adjusts
ACLs, it might make sense for it to consider core.sharedrepository.) Also,
the precise details of what file permissions git-annex uses don't need to
be documented well enough for the hook to replicate them if git-annex just
makes the permissions changes itself.</p>
<p>It seems to make sense that when restoring permissions, it should run the
that hook before changing the permissions. The freeze hook might do
something that prevents changing permissions and the thaw hook undo that.</p>