On 08/17/2011 01:39 PM, Christian Boltz wrote:
Hello,
on Mittwoch, 17. August 2011, Lars Müller wrote:
On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote:
We enabled it for nmbd and smbd in 11.4, which due to very flexible nature of smb paths that can be served made it reject valid user scenarios. It is kind of hard to confine a service which offers read/write access to configurable paths.
Hmm, sounds like a problematic addition. Maybe the restrictions should be lifted then.
Sounds more like the YaST Samba module needs an enhancement if a new share gets added. In this case we have to add a fitting AppArmor configuration for this new path too if AppArmor is in use.
The YaST Samba module is the wrong place IMHO. The better place is the Samba initscript (and its systemd equivalent) so that it is also working for people who manually edit smb.conf.
Copy&paste from my mail from yesterday (shortly before midnight) somewhere else in this thread:
---------------------------------------------------------------------
The main problem is that AppArmor needs to be aware of the location of your shares. The perfect solution would be that Samba or its initscript add the location of all shares (with lrwk permissions) to an AppArmor profile sniplet at startup.
See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most interesting comments:
| Comment 2 - Christian Boltz 2011-04-18 22:11:35 CEST | Agreed. It would still be worth some bonus points if the samba | initscript would auto-generate a profile sniplet with the path of all | shares ;-)
| Comment 3 - Lars Mueller 2011-04-20 18:30:08 CEST | Free coffee and cake if we see a submit request implementing the | suggestion from comment #2 in a way that it works generic with the | current sysvinit approach and with systemd too.
Lars didn't write "for the submitter only" - maybe there's someone who wants to make him sponsoring coffee and cake for the conference? *eg*
Another potential solution coming down the pipes are kernel vars and mount rules. Basically there could be a solution that doesn't have to directly update policy but only a single kernel var (easier to auto-gen), this could be done dynamically without having to reload all of policy. There are of course lots of details I have left out, and some more code to handle updating for shares would need to be created but at least for shares and dynamic filesystems I think there is a better solution coming than updating packages to do it.
---------------------------------------------------------------------
The bugreport already contains some technical hints - we just need someone who implements it. (If needed, I can help on the AppArmor part.)
Regards,
Christian Boltz
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org