On Tue, Mar 19, 2013 at 07:13:01PM +0400, "Артём Н." wrote: > Profile for the FatRat download manager. > I didn't test it carefully, but it works.
Nice. I've got a few comments inline.. > ----- > # > # FatRat apparmor profile. > # > > # vim:syntax=apparmor > > # Last Modified: Sun Feb 17 10:43:47 2013 > # Author: Artiom N. <[email protected]> > > #include <tunables/global> > > /usr/bin/fatrat { > #include <abstractions/base> > #include <abstractions/nameservice> > #include <abstractions/fonts> > #include <abstractions/freedesktop.org> > #include <abstractions/kde> > #include <abstractions/gnome> > #include <abstractions/user-download> > > # Not needed. > # #include <abstractions/ubuntu-bittorrent-clients> It would probably be better to just remove lines that aren't needed. It's one thing to leave them in while making changing changes to someone else's profiles and discussing them. > # Paranoia. > #include <abstractions/private-files-strict> > > /usr/bin/fatrat mr, > > /usr/bin/xdg-open rmix, > /usr/lib/fatrat/** rmk, > /usr/share/fatrat/** rmk, > /usr/share/kde*/** rm, > /usr/share/lintian/overrides/fatrat-data r, > > owner @{PROC}/*/ r, > # owner @{PROC}/net/dev r, > # root, root > @{PROC}/*/net/dev r, Same here, I'd think remove both commented lines > /home/ r, > owner @{HOME}/.config/Dolezel/fatrat.conf rwk, Is 'Dolezel' unique to your configuration? Or common for the application? > owner @{HOME}/.kde/share/config/kdebugrc r, > owner @{HOME}/.kde/share/config/kdeglobals rk, > owner @{HOME}/.kde/share/icons/** rk, > owner @{HOME}/.local/share/fatrat/ rwk, > owner @{HOME}/.local/share/fatrat/** rwmk, > > # Optional. > deny @{HOME}/Desktop/ rwmkl, > deny @{HOME}/Desktop/** rwmkl, > > } > ----- > > Also I've added @{TORRENT_CLIENT} in tunables/global and I've granted > permissions on execution it in browser's rules. > > tunables/global: > @{TORRENT_CLIENT}=/usr/bin/fatrat This is going to lead to trouble. What we have now is admittedly complex, but it is designed to avoid the user editing tunables/global directly -- once the user modifies the file, it'll be prompted about for upgrades for ever. That's why the current approach includes the other files, which users are encouraged to modify -- it'll be easier for them to accept/deny changes on upgrades in the future, or preseed settings at installation time. > abstractions/ubuntu-browsers.d/other (file, included in browser's profiles): > @{TORRENT_CLIENT} rPx, This doesn't really play nicely with the existing ubuntu-bittorrent-clients portion of policy, which gives torrent clients the sanitized_helper near-unconfined-status. (Not that near-unconfined torrent clients are a good idea; just a pragmatic idea. :) It'd be nice to have an easier way to migrate torrent clients to confined from the sanitized_helper over time. I'm not sure what the variables _ought_ to look like to help... Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
