# Reset des permissions Laravel — permissions Unix standard

Depuis la racine du projet, sur Ubuntu :

```bash
sudo bash ./bash_script/set_ownership.sh ubuntu --dry-run
sudo bash ./bash_script/set_ownership.sh ubuntu
```

Remplacer `ubuntu` par `master` pour TKO ou `adminkview` pour ACP.
Le propriétaire du code est obligatoire ; le groupe est toujours `www-data`.
`storage` et `bootstrap/cache` appartiennent toujours à `www-data:www-data`.
Le script retrouve la racine depuis son emplacement, indépendamment du dossier courant.

Prérequis : commandes standard GNU/Linux, compte et groupe existants.
Le compte de déploiement doit appartenir à `www-data` ; le script le vérifie
avant toute modification. PHP, les workers et les comptes cron doivent aussi
utiliser ce groupe pour écrire dans les dossiers partagés.

```bash
id ubuntu
# Si nécessaire, configuration administrative à réaliser séparément :
sudo usermod -aG www-data ubuntu
# Ouvrir une nouvelle session ; redémarrer les services concernés pour
# qu'ils prennent en compte leur nouvelle appartenance aux groupes.
```

| Cible | Permissions |
| --- | --- |
| Code, y compris fichiers cachés et liens eux-mêmes | propriétaire demandé : www-data |
| `storage`, `bootstrap/cache` et leur contenu | www-data : www-data |
| Code : dossiers / fichiers | 0755 / 0644 |
| `storage`, `bootstrap/cache` : dossiers / fichiers | 2775 / 0664 |
| Dossiers inscriptibles | setgid pour hériter du groupe www-data |
| Scripts `.sh`, `artisan`, exécutables existants des dépendances | 0750 |
| `.env`, `.env.*`, `.key`, `.pem`, `.p12`, `.pfx`, cache `config.php` | 0640 |
| Métadonnées `.git` : dossiers / fichiers / exécutables existants | 0700 / 0600 / 0700 |

Le setgid transmet le groupe aux nouveaux objets, pas leur propriétaire ni
le droit d'écriture. Configurer un umask compatible, généralement `0002`, pour
chaque processus qui écrit dans Laravel (PHP, workers, cron, déploiement).
Avec les modes de création habituels, cela donne des fichiers 0664 et des
dossiers 2775 sous un dossier setgid. Un mode explicitement restrictif imposé
par l'application peut limiter ces droits.

Un `umask 0002` dans un terminal ne configure pas les services déjà démarrés.
Le `umask 077` interne au script protège seulement son fichier temporaire ;
il ne modifie pas l'umask du terminal parent ni celui des services.
Les nouveaux fichiers appartiennent toujours au processus créateur.
Ne pas utiliser root pour Composer, npm ou Artisan.

PHP doit être propriétaire des fichiers runtime : Blade appelle `touch()` avec
une date explicite sur les vues compilées, ce que Linux réserve au propriétaire
(sinon `touch(): Utime failed: Operation not permitted`). Lancer donc les
commandes Artisan qui génèrent des caches en tant que `www-data` :

```bash
sudo -u www-data php artisan view:cache   # idem optimize, config:cache…
```

À défaut, terminer le déploiement par `php artisan view:clear`.

Aucun paquet ACL, `setfacl` ou `getfacl` n'est nécessaire. Le script ne crée
pas d'ACL et ne supprime pas les ACL étendus/par défaut déjà présents.
Si une ancienne version ACL a été exécutée, leur retrait est une migration
séparée : `chmod` seul ne suffit pas à supprimer les entrées ACL nommées
ou les ACL par défaut. Les modes ci-dessus décrivent la politique sans ACL étendus.

Exécuter pendant une fenêtre sans déploiement ni modification concurrente de
l'arborescence. Les liens symboliques ne sont pas suivis ; les cibles externes
restent inchangées. Le script refuse un storage/cache lié, les montages imbriqués,
liens physiques et fichiers spéciaux. Les exceptions doivent être traitées à part.

Cette version ne crée pas de sauvegarde automatique des permissions et ne
propose pas de restauration automatique. L'opération n'est pas atomique : en
cas d'erreur, corriger la cause puis relancer, ou utiliser une sauvegarde serveur
préalable pour retrouver les anciennes permissions.

Aucun compte, groupe, service, droit PostgreSQL, hook Git ou script hors du
projet n'est modifié. Les wrappers de `/usr/local/bin` restent hors périmètre.
Remplacer les anciennes corrections chown/chmod dans les hooks avant de les
réutiliser : elles pourraient annuler cette convention. Pour FundView,
utiliser `scripts/post-deploy.sh --skip-permissions`, puis le nouveau script.

Contrôler ensuite la connexion web, les logs/cache/uploads et les jobs sous
leur vraie identité (`cff_kron`, `tikeasy_kron`, etc.).