logrotate-selinux-i18n

Zdravím a obracím se na zkušenější Fedoráře s dotazem: Po upgradu serverů na F14 (u předchozích verzí jsem závadu nepozoroval) se každý týden objeví v audit logu následující záznam

type=AVC msg=audit(1295750467.735:20239): avc: denied { getattr } for pid=13419 comm=“service” path="/root/.i18n" dev=dm-0 ino=6242307 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
type=SYSCALL msg=audit(1295750467.735:20239): arch=40000003 syscall=195 success=no exit=-13 a0=898e628 a1=bff2a5c8 a2=29fff4 a3=1 items=0 ppid=13418 pid=13419 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=741 comm=“service” exe="/bin/bash" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

Nezdá se ale, že by to způsobovalo špatnou funkci logrotate. Dle mého názoru je logrotate zvědavé na obsah souboru /root/.i18n a selinuxu se to nelíbí. Pravidla selinuxu pro tohle chování uvolňovat nechci, protože se mi to taky nelíbí. Logrotate má dle mého názoru použít /etc/i18n a nestarat se o nastavení locales u roota. Netušíte někdo, co s tím? Nikde na webu jsem na řešení tohoto konkrétního problému nenarazil.

.i18n pro roota musím mít, a odlišné globální i18n také. Snad by mohlo logrotate běžet pod jiným uživatelem???

Zpravy SELinuxu jsou vzdycky silene krypticke. Podle me tady ale neni problem v logrotate, ale v tom ze logrotate pusti bash jako uzivatel root ten se snazi nacist i18n pro roota. Logrotate asi pod jinym uzivatelem nez rootem bezet nemuze, protoze presouva a prejmenovava logy, ke kterym ma pristup jen root. Jak to vyresit nevim - asi bych to ignoroval, nebo muzes zkusit zjistit, ktery rotacni skript to presne dela.

Díky, za snahu. Logrotate musí běžet s oprávněním roota, ale nemyslím si, že by musel zrovna mít uživatele roota i s rootovými konfiguračními soubory. Asi si správci distribuce myslí, že administrátor nemá co mít vlastní nastavení a musí používat default. Co když jako root budu mít nějaké nastavení pro bash, které skripty logrotate vůbec nezkousnou - třeba jinak nastavené cesty?
To samé měl ve zvyku spamassasin, cpát se do adresáře k rootovi. U něj se dá ale naštěstí nastavit speciální uživatel.
Konec filosofování, k věci:

Žádný rotační skript nevolá shell. V některých se ale volá /sbin/service a ten už volá shell - to bude asi ono - 3x se volá service reload a třikrát se audituje chyba. Hmmm, co s tím?

Zdravim

Ano je to tim, ze logrotate pousti prikaz “service”, v te chybove hlasce je to napsane. Respektive na ten soubor .i18n saha skript functions, ktery je includnuty skoro v kazde “sluzbe” a hned po spusteni si nastavuje locale, vetsinou skrz ‘/etc/profile.d/lang.sh’.

Mimochodem potvrzuji ze ti to zacalo delat az ve F14. Ve ctrnactce ma logrotate upravene skripty pro httpd a tusim ze i named vyuziva “sluzby” pro reload. Nemuzu ted overit, na svem laptopu mam porad 13tku a pracovni sem nechal v praci.

Zkusil bych si pohrat s kontextem, prip. ho restornout na defaultni pro cely adresar. Opet nemuzu slouzit co se defaultniho kontextu tyce, sam selinux nikde nepouzivam. Ale tusim ze spravny prikaz je

restorecon -v '/root/.i18n'

Pro jistotu mrkni do manualu nebo na net.

Pokud to nepomuze, muzes si upravit skripty, ktere pousti logrotate a ktere uzivaji “service” pro reload konfigurace a pouzit na to treba kill jako je to ve F13:

[kuku@cz-r8lgkkh ~]$ cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
	/bin/kill -HUP `cat /var/run/httpd/httpd.pid 2>/dev/null` 2> /dev/null || true
    endscript
}

Snad to pomuze. Obcas ty hlasky byvaj pekne otravne, proto jsem taky selinux zacal hned po instalaci vypinat :wink:

kuku.mp3

Díky, měl jsem být pečlivější a dohledat to sám. Omlouvá mne spousta jiné práce, mj. nastavování cisca, aby přes něj lezlo ipv6, nastavování ModRewrite v Apachi, aby si rozumělo s ipv6 a nadávání na ty trotly, co ipv6 vymysleli…
Se-linux na serverech nevypínám, považuji to za dobrý kus softu a mnohokrát mi dalo (bolestivě) najevo, že jsem někde něco nakonfiguroval jinak, než má být - za což jsem se-linuxu vděčen.
Kontext souborů je v pořádku (restorecon jsem zkoušel jako první už předtím, než jsem se zde ptal) a dělat speciální pravidlo pro logrotate nechci, už tak tam mám těch vlastních pravidel moc. Vrátím tam ten kill -HUP. Akorát, že při dalším upgrade budu zase lovit v paměti, co jsem kde dělal. To je vždycky porod.
A děkuji pěkně za pomoc!

Ja bych doporucoval to nahlasit jako bug - D. Walsh vetsinou na takoveto problemy reaguje pomerne rychle.