L'utilisateur ne peut pas toucher -t

Lors de la SCP sur mon serveur Fedora, un utilisateur continue de recevoir des erreurs de ne pas pouvoir modifier les horodatages des fichiers ("définir l'heure: opération non autorisée"). L'utilisateur n'est pas le propriétaire du fichier, mais nous ne pouvons pas chowndéposer de fichiers vers cet utilisateur pour des raisons de sécurité. L'utilisateur peut sudo, mais comme cela se produit via un client SCP / FTP, il n'y a aucun moyen de le faire non plus. Et enfin, nous ne voulons pas avoir à donner à cet utilisateur un accès root, juste pour lui permettre d'utiliser une synchronisation comme rsync ou WinSCP qui doit définir des horodatages.

L'utilisateur fait partie d'un groupe avec des rwautorisations complètes sur tous les fichiers et répertoires pertinents. Avez-vous des idées sur la façon d'accorder la permission de l'utilisateur à touch -tces fichiers spécifiques sans chownles lui communiquer?

Informations supplémentaires Tout cela a à voir avec l'activation du développement PHP dans un scénario à développeur unique (c'est-à-dire sans SCM). J'essaie de travailler avec Eclipse ou NetBeans pour travailler sur une copie locale du site basé sur PHP (WordPress), tout en permettant à l'utilisateur de prévisualiser "instantanément" ses modifications sur le serveur de développement. L'utilisateur travaillera à distance. Jusqu'à présent, toutes les tentatives de synchronisation automatique ont échoué - même en utilisant WinSCP en mode "dossier de surveillance", où il surveille un dossier local et tente de télécharger toutes les modifications jusqu'à l'erreur du répertoire distant car il essaie toujours de définir la date / l'horodatage .

L'utilisateur a un accès sudo, mais on m'a dit que ce n'était vraiment pas une bonne idée de travailler sous 'root', donc je n'ai pas voulu me connecter en tant que root pour faire ce travail. En outre, cela ne devrait pas être nécessaire. Je souhaiterais qu'un autre non-superutilisateur puisse faire la même chose - en utilisant les informations de son compte, établir une connexion FTP et pouvoir travailler à distance via la synchronisation. La solution doit donc fonctionner pour quelqu'un sans accès root.

Ce qui me stupéfie, c'est la difficulté que j'ai. Tous ces logiciels (NetBeans, Eclipse, WinSCP) sont conçus pour permettre la synchronisation, et ils essaient tous d'écrire l'horodatage. Cela doit donc être possible. WinSCP a la possibilité de désactiver "set timestamp", mais cette option devient indisponible (toujours "on") lorsque vous sélectionnez surveiller / synchroniser le dossier. Donc , il est obtenu d'être quelque chose qui est assez standard.

Étant donné que je suis un idiot complet en ce qui concerne Linux, et que je suis le "administrateur du serveur", je ne peux que supposer que c'est quelque chose d'idiot que je fais ou que j'ai (mal) configuré.

Résumé En un mot, je veux que tous les utilisateurs qui ont un accès de groupe r / w à un répertoire, puissent changer l'horodatage des fichiers dans ce répertoire via SCP.

Pourquoi ça ne marche pas

Lorsque vous essayez de changer l'heure de modification d'un fichier avec touch, ou plus généralement avec l'appel système sous-jacent utime, il y a deux cas.

• Vous essayez de définir l'heure de modification du fichier à une heure spécifique. Cela nécessite que vous soyez le propriétaire du fichier. (Techniquement, l'ID utilisateur effectif du processus doit être le propriétaire du fichier.²)
• Vous essayez de définir l'heure de modification du fichier à l'heure actuelle. Cela fonctionne si et seulement si vous avez la permission d'écrire dans le fichier. La raison de cette exception est que vous pouvez de toute façon obtenir le même effet en écrasant un octet existant du fichier avec la même valeur¹.

Pourquoi cela n'a généralement pas d'importance

• Lorsque vous copiez des fichiers avec ftp, scp, rsync, etc., la copie crée un nouveau fichier qui appartient à la personne qui a effectué la copie. Le copieur a donc la permission de régler les heures du fichier.
• Avec rsync, vous ne pourrez pas définir l'heure des répertoires existants: ils seront définis à l'heure à laquelle un fichier a été synchronisé pour la dernière fois. Dans la plupart des cas, cela n'a pas d'importance. Vous pouvez dire à rsync de ne pas se soucier des heures de répertoire en passant --omit-dir-times( -O).
• Avec les systèmes de contrôle de version, les dates de révision sont stockées dans des fichiers; les métadonnées sur les fichiers ne sont généralement pas pertinentes.

Solutions

Tout cela a à voir avec l'activation du développement PHP dans un scénario à développeur unique (c'est-à-dire sans SCM).

Ok, arrête là. Ce n'est pas parce qu'il n'y a qu'un seul développeur que vous ne devez pas utiliser SCM. Vous devez utiliser SCM. Demandez au développeur d'archiver un fichier et donnez-lui un moyen d'appuyer sur un bouton «déployer» pour extraire les fichiers de SCM dans le répertoire en direct.

Il n'y a absolument aucune raison technique pour laquelle vous ne devriez pas utiliser SCM, mais il peut y avoir une raison humaine. Si la personne qui travaille sur ces fichiers se dit «développeur», elle devrait utiliser SCM. Mais s'il s'agit d'une personne non technique insérant des documents, SCM peut être trop compliqué. Continuez donc à pousser les fichiers via FTP ou SSH. Cela peut fonctionner de trois manières.

• Avez-vous vraiment besoin de synchroniser les heures? Comme indiqué ci-dessus, rsynca une option pour ne pas synchroniser les heures. Scp ne le fait pas sauf si vous le lui dites. Je ne connais pas WinSCP mais il le peut probablement aussi.
• Continuez à faire ce que vous faites, ignorez simplement les messages sur les temps. Les fichiers sont toujours en cours de copie. Ce n'est pas une bonne option, car ignorer les erreurs est toujours risqué. Mais c'est techniquement possible.
• Si vous avez besoin de souplesse pour remplir les fichiers appartenant à l' apacheutilisateur, alors l'approche habituelle serait d'autoriser l'utilisateur SSH à accéder en tant que apache. L' approche la plus simple consiste à demander à l'utilisateur de créer une clé privée SSH et d'ajouter la clé publique correspondante à ~apache/.ssh/authorized_keys. Cela signifie que l'utilisateur pourra exécuter des commandes arbitraires en tant apachequ'utilisateur. Puisque vous êtes d'accord pour donner à l'utilisateur des droits sudo de toute façon, cela n'a pas d'importance dans votre cas. Il est possible, mais pas si facile, de mettre plus de restrictions (vous avez besoin d'une entrée de base de données utilisateur distincte avec un nom différent, le même ID utilisateur, un shell restreint et une prison chroot; détails dans une question distincte, bien que cela puisse déjà être couvert sur ce site ou sur Server Fault ).

¹ _{Ou, pour un fichier vide, écrivez un octet puis tronquez.}
² _{Sauf complications supplémentaires, mais aucune que je sache ne s'applique ici.}

Vous pouvez configurer rsync pour utiliser sudo sur l'extrémité distante comme ceci:

rsync -ave ssh --rsync-path="sudo rsync" /source/ user@host:/dest/