Hai due modi complementari per implementare questo:
Concedere agli utenti le autorizzazioni per utilizzare i gitrepository in remoto
Utilizzare gitolite3per fornire uno schema di repository hub-live (questo è descritto in dettaglio qui ), che richiede sostanzialmente di avere un barerepository (un repository hub ) per consentire agli utenti di eseguire il push / pull e una versione di check-out dello stesso repository (un repository live ) situato nel percorso appropriato /srv/www/html, ad esempio.
Mi piace usare gitolite3per gestire il repository hub , ma questo non è un requisito, anche se è piuttosto conveniente avere un controllo di accesso a grana fine associato al tuo LDAP di scelta, se necessario. gitolite3può fornire un controllo accurato fino al livello del ramo.
È anche buona norma limitare le capacità gitolite3dell'utente tramite sudoe gestire gli hook tramite sudochiamate. Questo è un esempio funzionante che utilizza gli gitolite3hook (sentiti libero di adattarli o di migliorarli / correggerli in base alle tue esigenze):
Il contenuto rilevante di /etc/sudoerso /etc/sudoers.d/gitolite3sarebbe qualcosa sulla falsariga di:
Cmnd_Alias GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /usr/bin/xargs, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Cmnd_Alias GITOLITE_APACHE_CMDS = /usr/sbin/apachectl graceful
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3 ALL = (root)NOPASSWD: GITOLITE_CMDS
gitolite3 APACHE_HOSTS = (root)NOPASSWD: GITOLITE_APACHE_CMDS
post-updategancio repository hub :
#!/bin/sh
echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"
sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
exit 0
publisher-hub2live script:
#!/bin/sh
echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"
cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master
# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info
exit 0
Limitazione della capacità di eseguire comandi non autorizzati in una shell di accesso
Quello che dovresti implementare è un metodo riproducibile e verificabile per limitare la capacità dell'utente di eseguire azioni diverse da quelle strettamente consentite.
Non è richiesto, ma aiuta se i tuoi utenti sono registrati in LDAP e hai già distribuito i meccanismi per eseguire l'autenticazione LDAP, sia tramite un modulo PAM, sia usando freeIPA e sssd.
Per implementare questo scenario, quello che faccio attualmente è il seguente (tenere presente che questo tipo di restrizioni richiede che vengano soddisfatte diverse condizioni, altrimenti la restrizione può essere facilmente aggirata):
- Gli utenti non appartengono al
wheelgruppo, l'unico autorizzato ad utilizzare su(applicato tramite PAM). Di solito, sysadmesiste un utente non LDAP ( ) per consentire agli amministratori fidati di eseguire azioni in caso di ripristino di emergenza o indisponibilità di LDAP.
Agli utenti viene fornito correttamente rbashun PATH di sola lettura che punta a un privato ~/bin, questa ~/bin/directory contiene collegamenti a tutti i comandi consentiti, ad esempio:
$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud 7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud 8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 git -> /usr/bin/git*
lrwxrwxrwx. 1 root dawud 9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
gli utenti sono date un ambiente di sola lettura limitata (si pensi a cose come LESSSECURE, TMOUT, HISTFILEvariabili). Questo per evitare shellfughe da comandi simili lesse garantire la verificabilità.
l'unico editor consentito è rvim, per lo stesso motivo. Gli utenti possono solo eseguire sudoedit, che è configurato per l'esecuzione rvimnella sudoconfigurazione:
Defaults editor=/usr/bin/rvim
se sono presenti restrizioni MAC (la distribuzione GNU / Linux specifica che si sta utilizzando ha SELinux abilitato), gli utenti vengono mappati all'utente SELinux staff_ue gli vengono dati i diritti per eseguire comandi come altri utenti come richiesto tramite sudo. Le specifiche sudorulesconsentite devono essere attentamente riviste per impedire all'utente di eludere queste limitazioni e possono anche essere implementate nell'infrastruttura LDAP esistente (questa è una delle funzionalità di FreeIPA).
gli utenti /home, /tmpe possibilmente /var/tmpsono polinistanziati tramite /etc/security/namespace.conf:
/tmp /tmp/.inst/tmp.inst-$USER- tmpdir:create root
/var/tmp /tmp/.inst/var-tmp.inst-$USER- tmpdir:create root
$HOME $HOME/$USER.inst/ tmpdir:create root
La polinstantiation delle directory non è una nuova funzionalità, è disponibile da molto tempo ormai. Come riferimento, vedi questo articolo del 2006 . È un dato di fatto, molti moduli usano già pam_namespacedi default, ma la configurazione predefinita su /etc/security/namespace.confnon abilita la polinstantiation. Inoltre, /etc/security/namespace.initdovrebbe rendere tutti i file scheletrici di sola lettura per gli utenti e di proprietà di root.
In questo modo è possibile scegliere se gli utenti possono eseguire qualsiasi comando per proprio conto (tramite un collegamento nella ~/bindirectory privata , fornito tramite /etc/skel, come spiegato sopra), per conto di un altro utente (tramite sudo) o nessuno.