CoolRaoul

Non seulement elle est toujours la mais elle est même non désactivable: (suis en 5.1 également)

L'update à été retirée a cause de faux positifs dans le centre de sécurité. Ca a été confirmé par un post d'un officiel Syno sur le forum officiel: "we have noticed this false alarm issue and working on the fix. the next update should fix this problem and will be available shortly."

Depuis longtemps je me suis aperçu que synoaudiod (/var/packages/AudioStation/target/sbin/synoaudiod) consomme du CPU en permanence. Ce matin j'ai voulu en avoir le coeur net et décidé d'investiguer plus avant A l'aide de la commande "truss", cross compilée avec le SDK, j'ai pu observer ce comportement select(1024, [3], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({1417247511, 826053}, NULL) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) gettimeofday({1417247511, 829573}, NULL) = 0 open("/tmp/AudioStation/player.list.json", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40091000 write(8, "{"last_update":1417247511,"uuid:"..., 582) = 582 close( = 0 munmap(0x40091000, 4096) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) nanosleep({0, 100000000}, NULL) = 0 et ca continue en boucle. Le plus étrange sont ces ouvertures/ecriture/fermeture frénétiques (10 fois par seconde!) dans "/tmp/AudioStation/player.list.json" Qui saurait me dire à quoi sert ce process et quels sont les conséquences de l'inhiber? J'aurais bien ouvert un ticket de support chez Syno, mais hélas j'ai un point de montage "/opt", et même si ce n'est pas du optware, sous ce prétexte, on me refuse toute aide tant que je n'ai pas effectué un reset usine de mon NAS.

Peut-être un espoir avec la toute nouvelle update DSM 5.1? https://www.synology.com/fr-fr/releaseNote/DS213j "Fixed an issue where cgi cannot be executed in Web Station"

A mon avis la piste est a creuser du coté de l'erreur "#!/usr/bin/perl: not found".

Gaffe: ici le cgi s'exécute sous le compte "root" et pas "http" car le "su - http" retourne immédiatement à la session initiale (sous réserve que le shell du compte ait été laissé à sa valeur par défaut, "/bin/false"): fserv> su - http fserv> id uid=0(root) gid=0(root) groups=0(root) Faut ajouter "-s /bin/sh" à la commande "su" pour éviter ça.

Normalement, ça devrait aussi marcher sans le "perl", sous réserve que le script soit exécutable (et c'est le cas d’après les résultats de tes "ls") et que la ligne shebang soit correcte Cependant l'erreur: /var/services/web/test.cgi: line 1: #!/usr/bin/perl: not found semble indiquer le contraire Es-tu sur que le .cgi à bien été créé avec Notepad++ configuré (préférences->nouveau document->format des sauts de lignes) pour utiliser les fins de lignes unix? Pour corriger: "édition" -> "convertir les sauts de lignes"

Ah non, au temps pour moi, la bonne commande est su - http -s /bin/sh -c "perl /var/services/web/test.cgi" (mais pourquoi avoir répondu auparavant "Donc dans SSH celà fonctionne avec cette ligne de commande" ?)

Faut plutôt faire ce test avec les droits du compte http, en s'y prenant comme cela: su - http -s /bin/sh -c "perl /var/services/web/cgi-bin/test.cgi"

Si j'ai utilisé cette formulation interrogative c'est juste que je n'ai pas pris le temps de valider la manip (y compris la partie restauration de conf) Mais je suis convaincu à 99% que ça fonctionne.

Pour commencer il faut s'assurer de l'accès au script CGI soit effectif pour le compte "http", groupe "http". C'est dans ce contexte que s'exécute le serveur apache

Ne suffit-il pas de programmer une sauvegarde *normale* dans laquelle l'option de sauvegarde de configuration est cochée et aucun dossier partagé sélectionné ?

Attention de bien lire tous les commentaires: le "remount" aurait plutôt pour effet de mettre globalement le file system contenant la source du bind en read-only Vérifie !

Et sinon, pour répondre à la question initiale, un "mount -bind" ignore l'option "ro" (parfois en l'indiquant par un warning): http://unix.stackexchange.com/questions/128336/why-doesnt-mount-respect-the-read-only-option-for-bind-mounts

J'ai le même problème, faute de temps pour tester plus avant, je pensais que ça venait de ma config.

Et donc quels sont les fichiers modifiés qu"il t'a détecté? (pour moi c’était le dossier "/root")

Mettre l'interface en anglais et relancer le security advisor, "_FICHIER_" sera alors remplacé par le nom du ou des fichiers/répertoires incriminés

Pour ma curiosité personnelle: pourquoi ne suis-je pas parvenu à trouver le code du start-stop-status de haproxy dans https://github.com/SynoCommunity/spksrc/tree/develop/spk/haproxy/src ? M'a fallu installer le package pour le visualiser Tu imagines bien qu'avant de proposer ça j'ai testé quand même ...

Le "su" (sans le "-") à pour effet d'inhiber l'exécution des profiles (on ne crée pas un *login shell* mais un shell simple). Comme le problème est du au resize dans "/etc/profile" ... CQFD

Je me demande si il ne serait pas plus efficace de remplacer les "su -" par des simple "su" dans le "start-stop-status" de haproxy On se préserverait ainsi des effets de bords de modifs à la hussarde de "/etc/profile" effectuées par d'autres packages ou par l'utilisateur lui-même

Pourquoi parles-tu de PS1? Sur mon NAS, après login, je ne trouve pas de caracteres de controle dans PS1: dans le "/etc/profile" par défaut c'est simplement "`hostname`> " qui est mis dans cette variable)

Je n'ai pas haproxy installé. Mais en attendant mieux, ne peut-on pas suggérer à ceux qui rencontrent le problème de simplement commenter le "resize" de "/etc/profile"?

Meme erreur: je pense que subprocess.check_output essaie de forker directement la commande ("exit" ici) et pas un sous-shell ("sh -c 'exit 0"") et donc il cherche un binaire "exit" dans le PATH et ne le trouve pas. Avec "ls" je n'en ai pas, mais c'est pas si étonnant vu qu’apparemment si il n'y a pas d'exécution de shell en login (sh -i). A noter que le stdout de "ls" ne s'affiche pas non plus (suis pas un spécialiste de python pour expliquer) En utilisant (pour forcer l'exécution des profiles): subprocess.check_output(['sh', '-l', '-c', 'pwd'], stderr=subprocess.STDOUT) Je n'ai toujours pas de caractères de contrôle ni d'erreur, par contre c'est plus long lorsque le "resize" est décommenté.

$ /usr/local/bin/python foo.py Traceback (most recent call last): File "foo.py", line 3, in <module> subprocess.check_output(['exit 0'], stderr=subprocess.STDOUT) File "/usr/lib/python2.7/subprocess.py", line 566, in check_output process = Popen(stdout=PIPE, *popenargs, **kwargs) File "/usr/lib/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory **EDIT**Meme erreur avec "/usr/local/python/bin/python" **EDIT#2** plus d'erreur en remplacant "exit 0" par "ls" et que le "resize" de /etc/profile soit commenté ou pas ne change rien

Suffit de commenter la commande "resize" dans /etc/profile