Pomylone przez wpisy ExecStartPre w pliku jednostki systemowej


23

Mam usystematyzowaną usługę, która musi utworzyć katalog /run, ale w przeciwnym razie działa jako użytkownik inny niż root. Z przykładu bloga wyprowadziłem następujące rozwiązanie:

[Unit]
Description=Startup Thing

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 -u /opt/thing/doStartup
WorkingDirectory=/opt/thing
StandardOutput=journal
User=thingUser
# Make sure the /run/thing directory exists
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /run/thing
ExecStartPre=/bin/chmod -R 777 /run/thing

[Install]
WantedBy=multi-user.target

Magia tkwi w 3 liniach następujących po komentarzu. Najwyraźniej ExecStartPrebędą działać w ten sposób jako root, ale ExecStartbędą działać jako określony użytkownik.

Doprowadziło to do 3 pytań:

  1. Co robi -przed /bin/mkdir? Nie wiem, dlaczego tam jest ani co robi.
  2. Jeśli ExecStartPrew pliku jednostkowym jest wiele znaków, to czy są one uruchamiane szeregowo w kolejności, w jakiej znajdują się w pliku jednostkowym? Lub jakaś inna metoda?
  3. Czy to rzeczywiście najlepsza technika do osiągnięcia celu, jakim jest utworzenie katalogu uruchamiania, aby użytkownik inny niż root mógł z niego korzystać?

Powodem, dla którego ExecStartPredziała jako root, jest PermissionsStartOnly=truedyrektywa. Ogranicza Userdyrektywę tylko do ExecStartpolecenia. Zobacz freedesktop.org/software/systemd/man/systemd.service.html
cayhorstmann

Odpowiedzi:


30

W przypadku jakichkolwiek pytań dotyczących dyrektyw systemowych można użyć man systemd.directivesdo wyszukania strony podręcznika man, która dokumentuje dyrektywę. W przypadku ExecStartPre=znajdziesz to udokumentowane w man systemd.service.

W dokumentacji dla ExecStartPre=znajdziesz wyjaśnienie, że wiodące „-” jest używane do zaznaczenia, że ​​awaria jest tolerowana dla tych poleceń. W takim przypadku jest tolerowany, jeśli /run/thingjuż istnieje.

Dokumenty tam wyjaśniają również, że „dozwolonych jest wiele wierszy poleceń, a polecenia są wykonywane kolejno jeden po drugim”.

Jedno ulepszenie metody wstępnego tworzenia katalogu nie powoduje, że jest on dostępny do zapisu na całym świecie, gdy potrzebujesz go tylko do zapisu przez konkretnego użytkownika. Bardziej ograniczone uprawnienia zostałyby osiągnięte dzięki:

 ExecStartPre=-/bin/chown thingUser /run/thing
 ExecStartPre=-/bin/chmod 700       /run/thing

To sprawia, że ​​katalog należący do konkretnego użytkownika jest w pełni dostępny.


Niesamowita odpowiedź, dziękuję za wskazówkę dotyczącą wskazówek systemd.d, zawsze trudno mi znaleźć systemd, gdzie się udać. To pomaga.
Travis Griggs

1
Powinieneś pokryć RuntimeDirectoryi RuntimeDirectoryModezbyt.
JdeBP

2

Odpowiedź na nr 3:

Sprawdź dyrektywy RuntimeDirectory=i RuntimeDirectoryMode=dyrektywy. Pełne dokumenty tutaj . Ale w skrócie (niewielka modyfikacja tekstu, ale esencja powinna pozostać):

RuntimeDirectory=

       This option take a whitespace-separated list of directory names. The 
       specified directory names must be relative, and may not include "..". If
       set, one or more directories by the specified names will be created
       (including their parents) below /run (for system services) or below 
       $XDG_RUNTIME_DIR (for user services) when the unit is started. Also, the  
       $RUNTIME_DIRECTORY environment variable is defined with the full path of 
       directories. If multiple directories are set, then in the environment 
       variable the paths are concatenated with colon (":").

       The innermost subdirectories are removed when the unit is stopped. It is 
       possible to preserve the specified directories in this case if 
       RuntimeDirectoryPreserve= is configured to restart or yes. The innermost 
       specified directories will be owned by the user and group specified in 
       User= and Group=.

       If the specified directories already exist and their owning user or group 
       do not match the configured ones, all files and directories below the 
       specified directories as well as the directories themselves will have their 
       file ownership recursively changed to match what is configured. As an 
       optimization, if the specified directories are already owned by the right 
       user and group, files and directories below of them are left as-is, even if 
       they do not match what is requested. The innermost specified directories 
       will have their access mode adjusted to the what is specified in 
       RuntimeDirectoryMode=.

       Use RuntimeDirectory= to manage one or more runtime directories for the 
       unit and bind their lifetime to the daemon runtime. This is particularly 
       useful for unprivileged daemons that cannot create runtime directories in 
       /run due to lack of privileges, and to make sure the runtime directory is 
       cleaned up automatically after use. For runtime directories that require 
       more complex or different configuration or lifetime guarantees, please 
       consider using tmpfiles.d(5).


RuntimeDirectoryMode=

       Specifies the access mode of the directories specified in 
       RuntimeDirectory= as an octal number. Defaults to 0755. See "Permissions" 
       in path_resolution(7) for a discussion of the meaning of permission bits.

Aby to wykorzystać, powinno to załatwić sprawę:

[Unit]
Description=Startup Thing

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 -u /opt/thing/doStartup
WorkingDirectory=/opt/thing
StandardOutput=journal
User=thingUser
# Make sure the /run/thing directory exists
PermissionsStartOnly=true
RuntimeDirectory=thing
RuntimeDirectoryMode=0777

[Install]
WantedBy=multi-user.target
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.