Fedora 23, Rsync Nie Działa

[marek353]

Gwoli ścisłości to jako polecenie terminala działa. Nie wykonuje jednak polecenia z crontab`a. Niedawno "przeprosiłem się"  z Fedorką po dłuższym okresie jej nieużywania i napotykam na głupi problem z zaplanowaniem crontab do robienia kopii zapasowej swojego katalogu domowego. Zawsze działało to bez zarzutu lecz teraz w najnowszej wersji systemu istnieje chyba jakieś zabezpieczenie SElinux w tym zakresie, którego nie mogę rozwikłać. 

 

Sprawdzam czy usługa jest uruchomiona? (tak)

# systemctl is-enabled crond.service
enabled

 

Nie można uruchomić rsync:

# systemctl enable rsyncd.service
Failed to execute operation: No such file or directory
 

$ systemctl status rsyncd.service
● rsyncd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

 

Jak uruchomić rsync? 

[@sunrise]

Najpierw zainstaluj rsync-daemon

[marek353]

Najpierw zainstaluj rsync-daemon

OK nie wiedziałem, że tak się teraz nazywa. Zainstalowałem, uruchomiłem:

# systemctl enable rsyncd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/rsyncd.service to /usr/lib/systemd/system/rsyncd.service.
 
 
# systemctl status rsyncd.service
● rsyncd.service - fast remote file copy program daemon
   Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

Proszę podpowiedz co dalej...? 

[@sunrise]

Proszę podpowiedz co dalej...? 

Zajżyj do logów, usługę skonfigurowałeś, cos mi sie wydaje, że masz błędne pojęcie o tym co ma robić rsync-daemon.

Może lepiej podaj to polecenie, które działa z konsoli a nie działa z cron i podaj gdzie je wpisałeś (w jaki pliku oraz jego zawartość),

Do przeglądania logów służy obecnie polecenie journalctl

[marek353]

Aby nie prokurować ewentualnych barier własnościowych plików sporządziłem bardzo prostego crontab`a w obrębie swojego katalogu domowego, z folderu do folderu o konkretnej godzinie. I tak on się przedstawia:

 

$ crontab -l

14 19 * * * /home/marek/.skrypty/back.sh

 

#!/bin/sh

rsync -av ~/Dokumenty ~/Obrazy /home/marek/spr

 

$ ls -la /home/marek/.skrypty

-rwxr-xr-x.  1 marek marek    57 01-22 19:12 back.sh

 

Teraz /var/log/rsync.log

 

2016/01/21 16:35:19 [758] rsyncd version 3.1.1 starting, listening on port 873

2016/01/21 17:55:49 [758] sent 0 bytes  received 0 bytes  total size 0

2016/01/21 20:34:26 [706] rsyncd version 3.1.1 starting, listening on port 873

2016/01/21 21:43:47 [706] sent 0 bytes  received 0 bytes  total size 0

2016/01/22 17:49:04 [741] rsyncd version 3.1.1 starting, listening on port 873

2016/01/22 17:51:23 [741] sent 0 bytes  received 0 bytes  total size 0

2016/01/22 18:51:34 [724] rsyncd version 3.1.1 starting, listening on port 873

 

Działanie samego rsync wykonane z terminala przebiega bez problemu. On powstaje kiedy użyję crontab i wtedy pewnie wkracza polityka zabezpieczeń SElinux, gdzie wymagane jest prawidłowe oznakowanie treści udostępnianych przez rsync. Należy oznaczyć pliki i katalogi typem "public_content_t". 

Pytanie- jak to zrobić?

[@sunrise]

#!/bin/sh
rsync -av ~/Dokumenty ~/Obrazy /home/marek/spr
 
$ ls -la /home/marek/.skrypty
-rwxr-xr-x.  1 marek marek    57 01-22 19:12 back.sh

Według mnie problemem jest to, że w skrypcie nie podajesz pełnych ścieżek, zauważ że ~ odnosi się do katalogu domowego ustawionego w zmiennych środowiskowych danej powłoki. Natomiast w crontabie najpewniej te zmienne nie są ustawione.

[marek353]

Używałem takiej formy skryptu od dawna z tą różnicą, że w innych systemach jak Fedora bez zabezpieczeń SElinux, i on działał. Uzupełnienie ścieżki dostępu niczego nie zmienia, uparcie cron się nie wywołuje.

Przyznaję ze skruchą iż polityki SElinux są mi nieznane, dopiero w Fedorze się z nimi spotykam. Jest wiele stron na ten temat i po wstępnej lekturze pewny jestem, że tu należy szukać przyczyny. Boję się jednak aby nie rozstroić nieświadomie zabezpieczeń, brak mi doświadczenia w tym zakresie. 

Wyświetliłem ustawienia SElinux tylko odnośnie cron i rsync:

 

$ getsebool -a
cron_can_relabel --> off
cron_system_cronjob_use_shares --> off
cron_userdomain_transition --> on
 
rsync_anon_write --> off
rsync_client --> off
rsync_export_all_ro --> off
rsync_full_access --> off

[@sunrise]

Jeżeli to faktycznie selinux to powinny być komunikaty w logu opisujące z czym jest problem. Przydatne mogą być polecenia audit2why -a oraz audit2allow -ae |grep 'allow\|!!'

Dobrze też jest przejrzeć logi związane z cronem journalctl -b _EXE=/usr/sbin/crond
Aby mieć 100% pewności, że to selinux możesz tymczasowo wyłączyć selinuxa poleceniem setenforce

[marek353]

Dwa pierwsze polecenia nie zwracają niczego, natomiast trzecie potwierdza brak autoryzacji usera "marek", tak wnioskuję.

 

# journalctl -b _EXE=/usr/sbin/crond
-- Logs begin at wto 2016-01-19 12:19:02 CET, end at sob 2016-01-23 11:50:24 CET
sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (RANDOM_DELAY will
sty 23 11:41:07 localhost.localdomain crond[899]: (root) Unauthorized SELinux co
sty 23 11:41:07 localhost.localdomain crond[899]: (root) FAILED (loading cron ta
sty 23 11:41:07 localhost.localdomain crond[899]: (marek) Unauthorized SELinux c
sty 23 11:41:07 localhost.localdomain crond[899]: (marek) FAILED (loading cron t
sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (running with inot
lines 1-7/7 (END)...skipping...
-- Logs begin at wto 2016-01-19 12:19:02 CET, end at sob 2016-01-23 11:50:24 CET. --
sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 19% if used.)
sty 23 11:41:07 localhost.localdomain crond[899]: (root) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool
sty 23 11:41:07 localhost.localdomain crond[899]: (root) FAILED (loading cron table)
sty 23 11:41:07 localhost.localdomain crond[899]: (marek) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spoo
sty 23 11:41:07 localhost.localdomain crond[899]: (marek) FAILED (loading cron table)
sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (running with inotify support)

 

Aby mieć 100% pewności, że to selinux możesz tymczasowo wyłączyć selinuxa poleceniem setenforce

 

Zanim to zrobię muszę wiedzieć jak potem na powrót aktywować selinux. W tym temacie brak mi jeszcze rozeznania. 

[@sunrise]

Zobacz czy masz uruchomiony auditd systemctl status auditd.service

setenforce 0 wyłącza

setenforce 1 włącza

w logach widać, że to selinux ale wiersz masz ucięty spróbuj polecenia journalctl -b _EXE=/usr/sbin/crond --no-pager

Być może twój problem jest związany z tym błędem https://bugzilla.redhat.com/show_bug.cgi?id=1298192

Możesz spróbować zainstalować ten poprawiony kernel poleceniem dnf update kernel --enablerepo=updates-testing albo poczekać aż go przeniosą do głównego repo

[marek353]

Teraz dostałem pełny log:

# journalctl -b _EXE=/usr/sbin/crond --no-pager

-- Logs begin at wto 2016-01-19 12:19:02 CET, end at sob 2016-01-23 13:12:01 CET. --

sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 19% if used.)

sty 23 11:41:07 localhost.localdomain crond[899]: (root) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/root)

sty 23 11:41:07 localhost.localdomain crond[899]: (root) FAILED (loading cron table)

sty 23 11:41:07 localhost.localdomain crond[899]: (marek) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/marek)

sty 23 11:41:07 localhost.localdomain crond[899]: (marek) FAILED (loading cron table)

sty 23 11:41:07 localhost.localdomain crond[899]: (CRON) INFO (running with inotify support)

sty 23 13:01:01 localhost.localdomain CROND[3505]: (root) CMD (run-parts /etc/cron.hourly)

sty 23 13:12:01 localhost.localdomain crond[899]: (root) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/root)

sty 23 13:12:01 localhost.localdomain crond[899]: (root) FAILED (loading cron table)

sty 23 13:12:01 localhost.localdomain crond[899]: (marek) Unauthorized SELinux context=user_u:user_r:user_t:s0 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/marek)

sty 23 13:12:01 localhost.localdomain crond[899]: (marek) FAILED (loading cron table)

 

Próbowałem w międzyczasie zmienić swój status z "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023" na "user_u" poleceniem 

# usermod -Z user_u marek

 

bez rezultatu:

# semanage login ­-l

usage: semanage login [-h] [-n] [-N] [-s STORE] [ --add -s SEUSER -r RANGE LOGIN | --delete LOGIN | --deleteall  | --extract  | --list -C | --modify -s SEUSER -r RANGE LOGIN ]

semanage login: error: one of the arguments -a/--add -d/--delete -m/--modify -l/--list -E/--extract -D/--deleteall is required

 

Dalej, audyt uruchomiony:

# systemctl status auditd.service

● auditd.service - Security Auditing Service

   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)

   Active: active (running) since sob 2016-01-23 11:41:06 CET; 1h 44min ago

  Process: 703 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)

 Main PID: 702 (auditd)

   CGroup: /system.slice/auditd.service

           └─702 /sbin/auditd -n

 

sty 23 11:41:06 localhost.localdomain systemd[1]: Starting Security Auditing ...

sty 23 11:41:06 localhost.localdomain auditctl[703]: No rules

sty 23 11:41:06 localhost.localdomain systemd[1]: Started Security Auditing S...

sty 23 11:41:06 localhost.localdomain auditd[702]: Started dispatcher: /sbin/...

sty 23 11:41:06 localhost.localdomain audispd[712]: priority_boost_parser cal...

sty 23 11:41:06 localhost.localdomain auditd[702]: Init complete, auditd 2.4....

Hint: Some lines were ellipsized, use -l to show in full.

 

Po wyłączeniu SElinux poleceniem "setenforce 0" nareszcie rsync ruszył, co daje już 100% pewności co do diagnozy problemu. Nie chcę jednak obniżać standardów i włączam go ponownie.

[@sunrise]

Tymczasowe obejście masz tutaj https://bugzilla.redhat.com/show_bug.cgi?id=1263328#c19 a docelowe do aktualizacja kernela

Czy masz zainstalowane pakiety setroubleshoot-server, setroubleshoot i setroubleshoot-plugins są bardzo pomocne przy problemach z selinuxem

[marek353]

 

Tych pakietów "setroubleshoot-server setroubleshoot setroubleshoot-plugins" nie miałem, ale już są zainstalowane.

I stało się, rozchrzaniłem sobie nieumyślnie uprawnienia selinux tym poleceniem:

usermod -Z user_u marek

Poskutkowało to nieprzyjemnymi skutkami, jak np. zablokowany dostęp do root przez "su", blokada google-chrome. Dalej już nie sprawdzałem co jeszcze. Powrót do stanu poprzedniego okazał się niemożliwy. Musiałem wyłączyć SElinux!

Nie wiem jak teraz wrócić do stanu z przed...

id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

 

albo tak skonfigurować te ostre reguły aby funkcjonalność była normalna?

 

Teraz odnośnie Twojego linka:

cat mycron.cil

cat: mycron.cil: Nie ma takiego pliku ani katalogu

 

# semodule -i mycron.cil

libsemanage.semanage_direct_install_file: Unable to open mycron.cil: No such file or directory

 (No such file or directory).

[@sunrise]

Oczywiście, że nie masz tego pliku musisz go stworzyć, w tym komentarzu użyto cat, tylko po to aby wyświetlić jego zawartość.

Co zwraca semanage login -l

jeżeli na liście masz użytkownika marek spróbuj

semanage login -d marek

Spróbuj usermod -Z marek

[marek353]

Oczywiście, że nie masz tego pliku musisz go stworzyć, w tym komentarzu użyto cat, tylko po to aby wyświetlić jego zawartość.

 

Ale jak i gdzie stworzyć?

 

Co zwraca semanage login -l

# semanage login -d marek
Login                Użytkownik SELinuksa Zakres MLS/MCS       Usługa
 
__default__          unconfined_u         s0-s0:c0.c1023       *
marek                user_u               s0                   *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *
 
 
# id -Z 
user_u:user_r:user_t:s0 
 
 
# usermod -Z marek 
Usage: usermod [options] LOGIN
 
Options:
  -c, --comment COMMENT         new value of the GECOS field
  -d, --home HOME_DIR           new home directory for the user account
  -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -g, --gid GROUP               force use GROUP as new primary group
  -G, --groups GROUPS           new list of supplementary GROUPS
  -a, --append                  append the user to the supplemental GROUPS
                                mentioned by the -G option without removing
                                him/her from other groups
  -h, --help                    display this help message and exit
  -l, --login NEW_LOGIN         new value of the login name
  -L, --lock                    lock the user account
  -m, --move-home               move contents of the home directory to the
                                new location (use only with -d)
  -o, --non-unique              allow using duplicate (non-unique) UID
  -p, --password PASSWORD       use encrypted password for the new password
  -R, --root CHROOT_DIR         directory to chroot into
  -s, --shell SHELL             new login shell for the user account
  -u, --uid UID                 new UID for the user account
  -U, --unlock                  unlock the user account
  -v, --add-subuids FIRST-LAST  add range of subordinate uids
  -V, --del-subuids FIRST-LAST  remove range of subordinate uids
  -w, --add-subgids FIRST-LAST  add range of subordinate gids
  -W, --del-subgids FIRST-LAST  remove range of subordinate gids
  -Z, --selinux-user SEUSER     new SELinux user mapping for the user account

Nie wiem jaką opcję wybrać? Poza tym "setenforce 0" działa tylko w bieżącej sesji, po resecie trzeba ponawiać.