On Friday, October 07, 2011 3:07 AM, "Christian Boltz"
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.
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 - it's possible to add "dynamic" shares that don't show up in smb.conf (for example using the "share directory" feature in KDE)
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.
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,
I might have read your post wrong but are you saying that Apparmor willl, by default, break the file/folder sharing feature built into KDE? This IMHO is completely wrong, you don't enhance security by simply breaking features, especially the most user-facing ones that are there in the GUI. IIRC Redhat was very careful not to deploy profiles for services in SELinux until they were well tested and work. Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org