Upstart propose une option de configuration (stanza en jargon Upstart) qui permet pour un job de charger un profile et de démarrer directement le job avec ce profile :
Par exemple, je donne le chemin direct vers le profile, upstart le charge, l'utilise et lance le processus. C'est une ligne à rajouter.
Commencer à devoir utiliser aa-exec, ça deviens vite chiant. Déja, si ton job upstart contient plusieurs lignes de commande, tu es obligé de faire un wrapper ( et donc il n'est plus "self contained" ), et tu dois charger à la main, en n'ayant pas le diagnostique de pourquoi ça ne marche pas, etc, etc.
Pareil avec systemd, qui propose dans la version git "SeLinuxcontext" pour démarrer le process dans un domaine particulier. En faisant ça dans systemd directement, tu as la capacité d'interroger systemd par dbus pour avoir l'info, tu as un retour plus haut niveau via journalctl ( ie, un vrai code d'erreur ), tu as une gestion intégré via les templates, etc, etc.
Pour le moment, tu peux pas dire "ce job est dans ce profile apparmor", mais un patch a été envoyé ( et il attends une version 3.0 avec divers modifs ).
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 5.
Upstart propose une option de configuration (stanza en jargon Upstart) qui permet pour un job de charger un profile et de démarrer directement le job avec ce profile :
https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/%2Bmerge/164169
Par exemple, je donne le chemin direct vers le profile, upstart le charge, l'utilise et lance le processus. C'est une ligne à rajouter.
Commencer à devoir utiliser aa-exec, ça deviens vite chiant. Déja, si ton job upstart contient plusieurs lignes de commande, tu es obligé de faire un wrapper ( et donc il n'est plus "self contained" ), et tu dois charger à la main, en n'ayant pas le diagnostique de pourquoi ça ne marche pas, etc, etc.
Pareil avec systemd, qui propose dans la version git "SeLinuxcontext" pour démarrer le process dans un domaine particulier. En faisant ça dans systemd directement, tu as la capacité d'interroger systemd par dbus pour avoir l'info, tu as un retour plus haut niveau via journalctl ( ie, un vrai code d'erreur ), tu as une gestion intégré via les templates, etc, etc.
Pour le moment, tu peux pas dire "ce job est dans ce profile apparmor", mais un patch a été envoyé ( et il attends une version 3.0 avec divers modifs ).