Hi Christian, On Fri, Oct 07, 2011 at 03:07:27AM +0200, Christian Boltz wrote:
am Donnerstag, 6. Oktober 2011 schrieb Lars Müller:
[ 8< ]
Can't we populate the apparmor cache as part of the installation/ upgrade/ maintenance of the system?
I'll enable caching, see my reply to Coolo's mail for details.
However I don't want to package the cached files because that might cause funny side effects on updates (profile changed locally, but packaged cache looks newer and such stuff).
I aggree. Packaging the cached files would be the wrog approach. What I had in mind is forcing a (re)build of the AA cache as part of the installation workflow. Or as part of software install. Or with other worfs: keep it away from the boot process. Even better have it ready when we boot. There aren't so many cases when the profiles need to be rebuid: a) After an update _if_ the location of a binary changed or one got added. b) Newly installed software. Then we need for the new binaries a rebuild.
AA caused issues to Samba in the past. Nevertheless I like to have it enabled by default again. With profiles wher we're not sure if they work correctly we might run it in complain mode.
That might be an option, but I'm not really happy with shipping profiles in complain mode - users probably expect that all profiles are in enforce mode.
Yes. You're right.
IMHO the better way is to ship them in the "extras" profile directory /etc/apparmor/profiles/extras/ where aa-genprof will pick them up as template.
That said: There's a better solution for the samba profile, see below.
This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \:
Indeed, I'm aware of https://bugzilla.novell.com/show_bug.cgi?id=688040
The quick and easy solution would be a little script that extracts the paths of all shares from smb.conf and writes an apparmor profile sniplet. This script should run when starting and reloading samba.
The downside is that it won't be aware of everything because - you can reload samba using SWAT instead of the initscript or systemd
I would ignore SWAT atm. We should have removed this old code from the packages. Not only to save us the extra work we had with the recent security update.
- it's possible to add "dynamic" shares that don't show up in smb.conf (for example using the "share directory" feature in KDE)
Which utilizes "net usershare" IIRC. "net usershare: usershares are currently disabled" is what I get on a default install. I know, there is an easy way to enable it from inside YaST and therefore we have to care about it. Uhh, ahh, it's broken in 3.6 anyway. https://bugzilla.samba.org/show_bug.cgi?id=8511
Covering all this makes things really difficult, therefore I'd say we should at least do the easy part (based on smb.conf) for 12.1. That's much better than the current state and will probably cover most usecases.
Yes.
If someone can provide a script that prints the path of all shares in smb.conf (there are some hints about python and perl modules to parse smb.conf in the bugreport) in the format given below I'll then integrate it in the initscript and systemd service file.
This is how the apparmor profile sniplet should look like:
# autogenerated at samba startup - do not edit! /path/to/share/ rk, /path/to/share/** lrwk, /another/share/ rk, /another/share/** lrwk,
Or an enhanced testparm allowing us to define which parameter(s) to display would be nice. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany