From 2ef31bb41f1f04a9d7341e7b2fe683f71e922097 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Nov 2007 22:49:53 -0500 Subject: store empty directories and restore in etckeeper init While working on this, I had to consider security policies -- is it ok if etckeeper init can run code from the /etc repository? I've decided this should be ok, and documented that it should only be run on trusted repos. Note that metastore could also be exploited by untrusted repos, and of course, note that you're checking out your *** /etc *** so it damn well better be trusted! With that determined, I decided to use a simple shell script to hold the empty directory info and allow them to be easily created. Expanding this for other files git can't represent is a possibility.. --- README | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) (limited to 'README') diff --git a/README b/README index 2cf8410..4900eeb 100644 --- a/README +++ b/README @@ -6,7 +6,7 @@ permissions of `/etc/shadow`. It's quite modular and configurable, while also being simple to use if you understand the basics of working with git. -## security warning +## security warnings First, a big warning: By checking /etc into revision control, you are creating a copy of files like /etc/shadow that must remain secret. Anytime @@ -23,6 +23,9 @@ it out world readable, before etckeeper fixes the permissions. The tutorial has some examples of safe ways to avoid these problems when cloning an /etc repository. +Also note that `etckeeper init` runs code stored in the git repository. +So don't use it on git repositories from untrusted sources. + ## what etckeeper does @@ -40,21 +43,19 @@ empty directories, and special files. git has only limited tracking of file metadata, being able to track the executable bit, but not other permissions or owner info. So file metadata storage is handled by `metastore`. Amoung other chores, `etckeeper init` -sets up a git hook that use `metastore` to store metadata about file -owners, permissions, and even extended attributes into a /etc/.metadata -file. This metadata is stored in git along with everything else, and can be -applied if the repo should need to be checked back out. +sets up a `pre-commit` hook that uses `metastore` to store metadata about +file owners, permissions, and even extended attributes into a +`/etc/.metadata` file. This metadata is stored in git along with everything +else, and can be applied if the repo should need to be checked back out. -git cannot track empty directories. So `etckeeper init` also sets up a git -hook to run `etckeeper pre-commit`, which checks for empty directories -before committing, and warns about them. You can then either ignore the -empty directory, if it's not significant, or put a file (such as -`.gitignore`) in the directory to enable git to track it. +git cannot track empty directories, but they can be significant sometimes +in /etc. So the `pre-commit` hook also stores information that can be used +to recreate the empty directories in a `/etc/.etckeeper` file. git doesn't support several special files that you _probably_ won't have in /etc, such as unix sockets, named pipes, hardlinked files (but softlinks -are fine), and device files. Again git hooks are used to warn if your /etc -contains such untrackable special files. +are fine), and device files. The `pre-commit` hook will warn if your /etc +contains such special files. ## tutorial @@ -127,14 +128,14 @@ Each etckeeper command uses `run-parts` to run the executable files in `/etc/etckeeper/$command.d/`. By default these directories contain a bunch of symlinks to the actual files; you can remove or reorder the symlinks, or add your own custom files. Each individual file is short, simple, and does -only one action. You can even just symlink in existing programs to run -them. +only one action. -For example, here's how to configure it to run `git-gc` after each apt run, +For example, here's how to configure it to run `git gc` after each apt run, which will save a lot of disk space: cd /etc/etckeeper/post-apt.d - ln -s /usr/bin/git-gc 99git-gc + (echo '#!/bin/sh' ; echo 'exec git-gc') > 99git-gc + chmod +x 99git-gc git add . git-commit -m "run git-gc after each apt run" -- cgit v1.2.3