9. FILESYSTEMS, UTILISATEURS, GROUPES, DROITS

9.1 Policykit - local authority - rights for reboot, mount usb etc..

Consolekit in wheezy does not behave well with startx, it's probably a matter of the session being active or not
Ether go back to the squeeze version, or manage the policykit yourself by creating .pkla files in the folder
/etc/polkit-1/localauthority/50-local.d  (that's the folder the most appropriate for our use)

% Info:
man pklocalauthority

ls /usr/share/polkit-1/actions/

% Sleep and hibernation
create a file, say 10-upower.pkla with

	[upower]
	Identity=unix-user:*
	Action=org.freedesktop.upower.*
	ResultAny=yes

% mounting drives
	[udisks]
	Identity=unix-user:*
	Action=org.freedesktop.udisks.*
	ResultAny=yes

% shutdown, reboot
	[stop]
	Identity=unix-user:manu
	Action=org.freedesktop.consolekit.system.stop
	ResultAny=yes

	[restart]
	Identity=unix-user:manu
	Action=org.freedesktop.consolekit.system.restart
	ResultAny=yes

9.2 Les droits d'endossement SetUID et SetGID

http://www.commentcamarche.net/faq/3603-securite-droits-d-acces-gnu-linux#iii-les-droits-speciaux

chmod 4644 fichier
chmod 4700 fichier
chmod 4755 fichier

chmod u+s  (4000)
chmod g+s  (2000)

Les droits d'endossement dans GNU/Linux sont représentés par :

    * la lettre s (si le droit x est positionné)
    * la lettre S (si le droit x n'est pas positionné)

Numériquement, les droits d'endossement sont représentés de la façon suivante :

    * 4000 - pour l'endossement de l'identité du propriétaire
    * 2000 - pour l'endossement de l'identité du groupe

Le comportement des droits d'endossement.

    * Pour les fichiers programme ou exécutable
          o SUID = 4000 - le processus a les droits du propriétaire du programme exécuté
          o SGID = 2000 - le processus a les droits du groupe du programme exécuté 
    * Pour les répertoires
          o SGID = 2000 - les fichiers qui se trouvent dans le répertoire appartiennent au groupe du répertoire

Les droits d'endossement sont très importants pour la sécurité.

Au lieu de donner l'accès à un fichier, on donne le droit d'accès à une commande.
Le kernel (ou noyau), au moment de l'exécution de la commande endosse l'identité du propriétaire ou du groupe de la commande au lieu de celle de l'utilisateur qui a lancé la commande.
Donc l'accès au fichier se fait par le biais de la commande et non pas directement.

Quand un utilisateur se connecte sur un système GNU/Linux, il détient 2 UID (UserIDentity) et 2 GID (GroupIDentity) : le réel et l'effectif.

    * Au moment de l'exécution d'une commande les UID et GID sont les réels,les effectifs sont attribués à la commande.
    * Quand les droits d'endossement ne sont pas positionnés, alors les UID et GID effectifs sont identiques aux UID et GID réels.
    * Si les droits d'endossement sont positionnés alors l'UID et/ou GID effectifs sont ceux de la commande. Ce qui veut dire que les UID et GID effectifs sont ceux qui contrôlent les droits d'accès à une commande

Pour connaître les fichiers avec les droits d'endossement de votre système tapez dans un terminal la commande suivante :

# find / -perm -2000 -o -perm -4000 -exec ls -l {} \; 2>/dev/null

Un bon exemple c'est la commande crontab. Cette commande crée un fichier dans /var/spool/cron/crontabs pour l'utilisateur qui a exécuté la commande crontab. L'accès au répertoire /var/spool/cront/crontabs est interdit aux utilisateurs sauf root.

$ cd /var/spool/cron/crontabs/ 
bash: cd: /var/spool/cron/crontabs/: Permission non accordée

Quand l'utilisateur lance la commande crontab -e (pour éditer son fichier /var/spool/cron/crontabs/nom_user), la commande s'exécute avec l'UID et GID réel de l'utilisateur mais avec l'UID et GID effectif de root.

$ ls -l /usr/bin/crontab 
-rwxr-sr-x 1 root crontab 26872 2004-07-28 22:44 /usr/bin/crontab

On voit que la commande crontab est la propriété de root et qu'elle fait partie du groupe crontab avec le droit SGID.

Et comme root a le droit de créer dans /var/spool/cron/crontabs le fichier sera créé.

# ls -l /var/spool/cron/crontabs/lami20j 
-rw------- 1 lami20j crontab 225 2006-07-22 16:00 /var/spool/cron/crontabs/lami20j

On voit que l'utilisateur lami20j est le propriétaire du fichier et qu'il a les droits de lecture et d'écriture. Cependant il ne peut pas le faire directement.

9.3 Begin:waiting for resume on startup, resume process

The resume script check if the swap partition exists.

1. first make the swap partition work again by
sudo mkswap /dev/sda6
(where sda6 should be the corresponding partition on your system. Check gparted to ensure this. This will DESTROY all your data if you use it on a data partition, like your /home one)
(if not working (occupied), you need to free it
swapoff /dev/sda6
)

2. then compute the UUID of the new swap partition
sudo blkid /dev/sda6

3. change the UUID code in both these files
/etc/fstab
(only change the one concerning /dev/sda6!)
/etc/initramfs-tools/conf.d/resume

4. rebuild the initramfs with
update-initramfs -u

5. reboot

You can also change back the swap UUID with this command (thanks Lowell)
    mkswap -U UUID /dev/swapdev
where UUID is the ID shown in both mentioned /etc files (the ID should be the same in both them, otherwise follow the 1-3 steps!)

9.4 Forcer le montage en ecriture d'une partition ntfs apres un mauvais demontage de windows

demonter le disque
puis le monter avec l'option force:
sudo mount -t ntfs-3g /dev/sdb1 /media/StorageDisk -o force

9.5 Disque externe en lecture seule

cat /etc/mtab
/dev/sdc1 /media/Storage fuseblk rw,nosuid,nodev,noatime,allow_other,blksize=4096 0 0

sudo vol_id -u /dev/sdxx
UUID : 0C3C5FC03C5FA40C

defaults Correspond a rw,suid,dev,exec,auto,nouser et async
# gid=100 assignera l'ensemble des fichiers au groupe dont le gid (pour group id, identifiant de groupe) est 100. Sous Ubuntu, le gid 100 correspond au groupe users, auquel tous les utilisateurs font normalement partie. Vous pouvez retrouver une liste de tous les groupes existants sur votre machine avec leur gid dans le fichier /etc/group. Si vous omettez cette option, tous les fichiers seront assignés au groupe 0, soit root (le compte système).
# uid=1000 assignera l'ensemble des fichiers de la partition à l'utilisateur dont l'UID (pour User ID, identifiant d'utilisateur) est 1000. Sous Ubuntu, l'UID 1000 correspond au premier utilisateur, créé lors de l'installation de Ubuntu. Si vous omettez cette option, tous les fichiers seront assignés à l'utilisateur root (le compte système).
# L'option umask=002 donnera les droits d'accès, sur l'ensemble des répertoires et fichiers, en lecture et en écriture à tous, de même qu'en exécution au propriétaire du fichier.

9.6 Utilisateurs et groupes

Utilisateurs : (/etc/passwd    /etc/shadow)

useradd -m          -m pour creation automatique du dossier dans home  
passwd -d USER  (vide le passwd, l'utilisateur le change en tappant passwd)
usermod
addgroup user group
userdel
id
groups

Groupes :  (/etc/group   -> gid et membre du groupe)
groupadd
groupmod
groupdel

Droits fichiers dossiers : 
chmod 770 fold
chown -R user:group fold
chown :gid fold
chown uid fold
chmod u=rwX,g=rwXs,o=--- fold  -> le s est important, tous les fichiers creer dans le dossier et sous dossier appartiennent au grope

9.7 Droits partage dossier fichiers

Les bases de droit UNIX

Les droits sous unix dans leur version POSIX sont relativement simples. Un utilisateur est défini par un identifiant et un groupe. Le nom de ce groupe est généralement le même que le nom de l'identifiant. Ainsi lorsque l'on crée un nouvel utilisateur par la commande adduser gaston, est automatiquement fabriqué l'identifiant gaston ET son groupe gaston. L'idée sous-jacente de ce groupe un peu spécial, est que seul l'utilisateur y appartient et personne d'autre.

La commande addgroup permet quant à elle d'ajouter de nouveaux groupes qui ne sont à l'origine liés à aucun utilisateur. Après il est possible d'ajouter arbitrairement un utilisateur à un de ces groupe avec la commande usermod. Un utilisateur est donc le seul à appartenir au groupe qui porte le nom de son identifiant, mais peut appartenir à plein d'autres groupes.

Chaque ressource (fichier ou un dossier) est décrit par un groupe, un identifiant et trois niveaux de droits. Chacun de ces trois niveaux correspond à une des conditions suivantes appliquée à l'utilisateur qui tente d'accéder à la ressource :

1. u ou user - Son identifiant est celui de la ressource.
2. g ou group - Il appartient au groupe de la ressource.
3. o ou other - Il n'est ni du bon groupe, ni du bon identifiant.

A chacun de ses niveaux correspond une série d'autorisation : droit de lecture (r), droit d'écriture (w) et droit d'exécution (x). Sachant qu'exécuter un dossier consiste sous Unix à pouvoir rentrer dedans... Ainsi lorsqu'un utilisateur accède à une ressource, UNIX cherche la première condition vérifiée, regarde les droits qui correspondent et les applique. La commande pour changer les droits sur une ressource est chmod. Par exemple chmod gu+rw,o-rw, donne un accès lecture (r) et écriture (w) pour la condition (1) et (2), et aucun droit pour la condition (3).

Lorsqu'un utilisateur fabrique un fichier, ce dernier lui appartient, c'est à dire que le groupe et l'identifiant du fichier sont ceux de l'utilisateur (d'où l'intérêt du groupe privé). Les droits du fichier sont généralement de type rw pour groupe et propriétaire, et r seulement pour les autres. Ces droits par défaut peuvent cependant être changés par la commande umask qui permet d'enlever des droits aux fichiers créés. Par exemple umask go-w fera que tous les prochains fichiers n'auront plus le droit d'écriture que sur o (le propriétaire). L'umask par défaut est donc o-w.

Pour une information plus poussée sur les droits unix, je vous conseille de lire l'excellent article sur wikipedia.
Première approche du partage

Par "partage", il faut entendre ici "système de fichier". Il n'est absolument pas question de NFS, CIFS ou autre appareillage du même acabits. L'idée de départ du besoin est la suivante :

* Sur une machine j'ai des utilisateurs, disons gaston, josette et robert
* J'ai des dossiers qui sont chacun partagés par un ensemble différent d'utilisateurs. Le dossier /photos est partagé par josette et gaston, mais /vidéos l'est par gaston et robert.
* Je veux que lorsqu'un utilisateur crée une ressource (dossier ou fichier) dans un dossier (ou sous-dossier), les autres utilisateurs ayant accès à ce dossier puisse modifier cette ressource.

Simple n'est-ce pas ? On se dit dans une première approche qu'il suffit :

1. De créer autant de groupes que de dossier.
2. De changer les droits de chaque dossier (de manière récursive) de sorte à les donner au groupe en écriture.
3. D'ajouter dans ce groupe chaque utilisateur ayant accès au dossier.

Ce qui nous donne :

# création des utilisateurs
adduser gaston
adduser josette
adduser robert

# création des deux groups
addgroup acces-photos
addgroup acces-videos

# changement des droits sur les dossiers : lecture/écriture/traversée pour groupe et utilisateur, rien pour les Autres.
chown o-rwx,gu+rwX /vidéos /photos -Rc
Le mode d'accès de `/vidéos/nos_vacances.avi' a été modifié à 0660 (rw-rw----).

# changement du group d'appartenance
chown :acces-videos /vidéos -Rc
chown :acces-photos /photos -Rc

# ajout des utilisateurs aux différents groups
usermod -a -G acces-videos,acces-photos gaston
usermod -a -G acces-videos josette
usermod -a -G acces-photos robert
root#

A partir de là tout va bien ou presque, car les ennuis commencent lorsqu'un utilisateur commence à créer un fichier dans un partage. Comme nous l'avons vu plus haut, ce nouveau fichier héritera de l'identifiant et du group de l'utilisateur qui l'aura crée. La conséquence, à cause de l'umask par défaut, est l'impossibilité d'être modifiée par qui que ce soit, vu que tout le monde est other dans ce cas de figure.
Droit SGID et SUID

Les droits SUID et SGID s'appliquent généralement aux exécutables en donnant à l'utilisateur qui les lancent les mêmes droit que l'utilisateur (SGID) ou le groupe (SGID) auquel l'exécutable appartient. Ainsi sur une commande appartenant à root, un chmod u+s permettrait à n'importe qui de la lancer AVEC les droits root...

Dans le cas qui nous intéresse, SGID a une propriété un peu moins connue. En effet lorsque cette fois c'est un dossier qui dispose du droit SGID, tous les dossiers et tous les fichiers qui seront créé immédiatement en dessous auront le même groupe que lui. Plus intéressant encore, tout dossier créé aura en plus le SGID de positionné.

Ainsi notre problème se règle très simplement en positionnant au départ le SGID sur tous les dossiers (et seulement les dossiers !!) :

root#find /vidéos -type d -exec chmod g+s {} \;
root#find /photos -type d -exec chmod g+s {} \;
root#

Ensuite, SGID étant positionné, tous les prochains fichiers créés ici auront le bon groupe et tous les nouveaux dossier le SGID.
Conclusion

L'avantage de cette approche est que la majorité des applications qui vont accéder au système de fichier vont respecter ces droits. Maintenant ce n'est pas l'absolue panacée car le fichier ou le dossier continue d'appartenir à l'utilisateur qui l'a créé, et rien ne l'empêche d'aller modifier les droits, y compris le SGID. Il y a aussi certaines applications comme tar qui vont modifier ces droits et l'on risque alors à nouveau l'incohérence. Mais cette méthode règle une grande partie des problèmes et une petite tâche CRON peut venir finir le travail.

9.8 org.freedesktop.hal.storage

sudo nano /etc/PolicyKit/PolicyKit.conf
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!-- See the manual page PolicyKit.conf(5) for file format -->

 <config version="0.1">
         <define_admin_auth group="users"/>
        <match action="org.freedesktop.hal.power-management.shutdown">
                <return result="yes"/>
        </match>
        <match action="org.freedesktop.hal.power-management.reboot">
                <return result="yes"/>
        </match>
        <match action="org.freedesktop.hal.power-management.suspend">
                <return result="yes"/>
        </match>
		<match action="org.freedesktop.hal.power-management.hibernate">
                <return result="yes"/>
        </match>
        <match action="org.freedesktop.hal.storage.*">
                <return result="yes"/>
        </match>
        <match action="hal-storage-mount-fixed-extra-options"> <!-- for internal devices mounted with extra options like a wished mount point -->
                <return result="yes" />
        </match>
        <match action="hal-storage-mount-removable-extra-options"> <!-- for external devices mounted with extra options like a wished mount point$
                <return result="yes" />
        </match>
</config>

Emmanuel Branlard
http://emmanuel.branlard.free.fr/