Sticky bit on folders

Posted on by
1

Removing file rules:

Every user with write permission on the directory can delete a file. (also if it is not write allowed on it)

Sticky bit (t) on directories:

stat -c '%a %n' /tmp/
1777 /tmp/
ls -ld /tmp
drwxrwxrwt 26 root root 69632 Sep 24 09:17 /tmp

tmp directory has sticky bit set on others. (see t permission)
At remove file time, ignore permissions: only owner of file or directory can delete it.

Sharing repositories by file-permission with git

Posted on by
3

In this post I will cover the subject of sharing git repositories in the simplest way, i.e. using file permissions.

First we’ll analyze sharing directories on a unix system, then we’ll see it applied to git repositories.

setuid (u+s) and setgit (g+s) on directories:

Despite of who has created a file inside a direcotry, that file will have owner and/or group same as owner and/or group of the owner of the directory.
Note: Only new directories inherit this bit.

Sharing directories:

cd sahred-dir/
chown user:team -R .
chmod g=u,o= -R .
find . -type d -print0 | xargs -0 chmod g+s
vim /etc/profile --> setting umask 002

Remember:

  1. manually enable sticky bit on already created directories (only new ones inherit it)
  2. umask is very important: with umask 022, sharing will not work: group need same access as owner.
  3. people sharing this folder must be a ‘team’ group member

Sharing directory , umask set by ACL:

A fine grained approach is to set umask 002 ONLY on this direcotry.
We need ACL to accomplish this task.

vim /etc/fstab --> add ACL as option on filesys hosting our shared-dir
mount -o remount <that filesys>
setfacl -d -m mask:007 -R shared-dir

Useful (backup&restore permissions):

getfacl <file> > backup.acl
getfacl -R <dir> > backup.acl #recursive
setfacl –restore=backup.acl

Sharing git repositories:

When sharing a repository with git, the shared repository is the one receiving pushes.
Any clone is supposed to be used by only one user => no need to set setgit bit inside those clones.

git init --bare --shared=group

This command will create a bare repo with setgid on directories.
This is a shared folder.
When people (inside a ‘team’ group) pushes to this repo, git objects will have always the same ‘team’ group despite of who is pushing.

Note: git sets

 core.sharedrepository = 1

to properly manage file creation regardless of  umask value.

References:

Drupal develop-publish cycle from command line: git + drush

Posted on by
Reply

In this blog I will show how to automate the develop/publish phases during the creation of a Drupal site .

Goals:

  1. Keep the entire Drupal site (files, modules, db) under git configuration control.
  2. Automate storage of new site versions during development
  3. Automate deploying on production site
  4. Provide oneliners to commit, publish, deploy, roll-back operations

Use cases:

  1. Needing site versions under configuration control
  2. Multiple people developing in parallel
  3. Developing on different workstations, not directly connected together

Post layout:

  1. Phase 1 – Setting up development environment
  2. Phase 2 – Setting up the central repository
  3. Phase 3 – Develpoing – Testing – Committing – Pushing
  4. Phase 4 – Setting up a twin developmnet environment
  5. Phase 5 – Updating live site

Tools/Prerequisites:

  1. git and drush installed on any develop machines
  2. at least drush installed on production machine
  3. ssh shell access on both develop and production machines
  4. A central git repository (reachable by both develop and production sites). For instance github or bitbuckect (which offers unlimited free public or private repositories)

This post is primarily a way for me to trace my work, but I hope it could be useful to someone else too.

This post is based on many many articles on the web, here some of the most important:

Pages: 1 2 3 4 5 6