aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/lockdown_hooks.mdwn
blob: c190ccd53bdea00ac2eb82e1fa481454a63454a5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Add git hooks that are used to [[internals/lockdown]] annexed objects.
--[[Joey]]

Use cases include:

* Setting immutable bit on systems where git-annex is given the ability to
  do so, to fully guard against accidental deletion in all circumstances.

* For systems that ignore the write bit, but have some other way to prevent
  write to a file (eg, ACLs or something).

  Note that in such a case, `git-annex init`'s probe of the write bit
  handling fails; as long as the hook is configured globally, it should
  run the hook instead, and if it works, can avoid direct mode.

Design:

Configs: annex.lockdown-command, annex.unlockdown-command
In these, "%path" is replaced with the file/directory to act on.

Locking down a directory only needs to do the equivilant of removing its
write bit, does not need to lockdown the files within it.

It would be up to the command to decide how to handle the 
core.sharedRepository configuration.

These could be set in the global gitconfig file. The IncludeIf directive
can be used to make them be used only for repositories located within a given
mount point.

git-annex test disables use of global gitconfig settings. There would need
to be a way to let it use these.

Perfomance:

Hook would be called twice per store/drop of an annexed object, 
once for the file and once for the parent directory.

On windows, called four times per lock of an annexed object, to first thaw
it and then freeze it. This could be reduced to 2, I think. 
On posix, the file is locked without being thawed, 
as only read access is needed.

Probably running a shell script is not too much overhead in many cases,
if it was too slow, there could be a variant that is run once and 
fed the names of files to operate on via stdin.