[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-factory
Subject:    Re: [opensuse-factory] Tumbleweed update to 20200201 removed /etc/services
From:       Christian Boltz <opensuse () cboltz ! de>
Date:       2020-02-07 22:42:40
Message-ID: 79059800.ioybi0cYTZ () tux ! boltz ! de ! vu
[Download RAW message or body]

Hello,

Am Donnerstag, 6. Februar 2020, 09:04:27 CET schrieb Stefan Seyfried:
> Am 05.02.20 um 20:29 schrieb Christian Boltz:
> > Silly question - why did you switch it off before? ;-)
> 
> Because it always™ breaks something ;-)
> 
> No, apparently I actually did not disable it after the last reinstall
> on this machine IIRC, I need to improve my documentation for reinstall
> to not forget this again ;-)

Well, actually you just confirmed what I see whenever I give my 
"AppArmor Crash Course" talk ;-)

I always ask the audience to raise hands if they a) use AppArmor and 
b) use AppArmor "accidently" (because they use (open)SUSE, Ubuntu, 
Debian Buster etc.)

For b) I usually see at least twice the hands as for a) - which means 
that AppArmor typically just works in the background, doesn't cause 
trouble, and most people even don't notice that it's active ;-)

> > Please check if you have *.rpmnew files in /etc/apparmor.d/ or
> > /etc/apparmor.d/abstractions/ - one of the latest snapshots included
> > updated abstractions for the /usr/etc/ move.
> 
> Exactly. I checked the changelog and even rebooted to make sure
> everything is fine.

OK, the reboot includes reloading the profiles - which would have been 
my first guess.

> > If you don't have any *.rpmnew files and still see problems, please
> > open a bugreport with your /var/log/audit/audit.log (you can grep
> > for "apparmor" if you don't want to attach the whole file).
> 
> It boils down to:
> 
> type=AVC msg=audit(1580924683.326:179): apparmor="DENIED"
> operation="open" profile="nscd" name="/usr/etc/services" pid=3405
> comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> 
> And I don't understand why by reading the apparmor config.
> But "aa-teardown;systemctl disable apparmor" fixed it for me.

Hmm, that's really strange, and shouldn't happen - as you already wrote 
in a later mail, abstractions/nameservice includes
  /{usr/,}etc/services       r,
which should cover this.

Just to be sure, please check if
    rpm -V apparmor-profiles apparmor-abstractions
lists any modified files.


Usually I don't use nscd [1], but I just started it and let it run for 
two hours - without a denial in audit.log. (Just wondering, even if your 
denial is completely strange - do you use a non-default nscd config?)

Instead of using aa-teardown, can you please re-enable AppArmor and set 
the nscd profile into complain (learning) mode?
    aa-complain /etc/apparmor.d/usr.sbin.nscd
(I guess you know what complain mode does, but for the wider audience: 
complain mode means everything is allowed, and things that would be 
denied get logged. There's also aa-enforce to switch back to enforce 
mode.)

After having nscd run for a while, check if you get ALLOWED log entries 
for it.

If you don't find an obvious reason for the problem, feel free to send 
me a tarball of your /etc/apparmor.d/ (off-list), and I'll have a look 
at it.


Regards,

Christian Boltz

[1] it caches "too much" for me, and since I run a local nameserver,
    nscd isn't too useful ;-)
-- 
<cboltz> oh, "test is green" fails? nice ;-)
<tampakrap> hahahaha yes
<tampakrap> we never thought of that scenario
[from #opensuse-admin]



--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]