Hello,
Am Sonntag, 2. Juni 2013 schrieb Kshitij Gupta:
> I'm awaiting an approval for my wiki.apparmor account,
John did that yesterday, so you should be able to write in the wiki ;-)
> @Christian, about saving the changes idea, do you propose a method to
> add a line to the profiles specifying the switch to use (save to
> profile/add to local/always ask) ? That could be done by simply
> adding a top line to each profile (maybe in a comment?), that way we
> dont mess with the profile and if the profile has no option we get to
> the default.
Yes, something like that - and doing it as comment also sounds like a
good idea.
The tools should search for that comment in the main profile and in
local/. If both contain different comments, the comment in local/ should
win.
For writing, I'd say
- "save to profile" means the comment should get added to the profile
- "save to local" means the comment should get added to local/ (the goal
is not to modify the main profile in this case)
- "always ask" probably means no comment at all
> Also, could you elaborate on:
> > Talking about feature ideas - it would be nice to have profile
> > modification scriptable. I'm thinking about something like
> >
> > aa-$toolname --profile "/usr/sbin/httpd2-prefork" \
> > --addhat "vhost_foo"
> > aa-$toolname --profile "/usr/sbin/httpd2-prefork//
> > vhost_foo" \
> > --add '/home/foo/httpdocs/** r'
>
> I understand you wish to allow the user to pass entries to the profile
> via the command line. Now, which tool could be used for this purpose
> (aa-genprof or aa-easyprof?) ?
It probably fits best in the planned profile merge tool (basically the
commandline switches are profile sniplets). aa-easyprof (as suggested by
Seth) might be an alternative, or a small standalone tool.
> and what if the user entry contradicts
> a previous entry?
That's something that will rarely happen because most rules can't
conflict. The only exception are ix vs. Px vs. Ux vs. Cx - in this case,
failing with an error message is the way to go.
Hmm, maybe a --force option to replace conflicting lines would be an
idea, but that's really a corner case.
> and does the tool execute after appending the
> profile attribute to file or does it exit with a success or failure
> message?
If everything works, it should update the profile and reload it.
No success message needed (except if -v/--verbose is specified).
If something fails, then it should of course print an error message.
> As, Seth mentioned there is a default set of profiles and then there
> are the user-generated/modified profiles. Now, we could provide for a
> separate place to store the user generated/modified profiles and keep
> the default ones intact.
Interesting idea, but there are some limitations we have to keep in
mind. The profiles are loaded early at boot, which means (at least on
some distributions) that not all filesystems are mounted at this stage.
In other words: the profiles have to be on the / filesystem, and /etc/
typically is on / [1].
In theory we could have a subdirectory somewhere in /etc/, but I'm
afraid it would cause some confusion for users to have the active
profiles at multiple locations.
(Maybe we could have a "backup" somewhere, but that's mostly a packaging
thing. Besides that, people could just delete the modified profile and
re-install the apparmor-profiles package.)
> Sometimes, the user generated profiles may
> screw up. (I ended up messing up my Firefox profile while playing
> with aa-genprof as a consequence to which my Firefox would never
> start-up).
;-)
Regards,
Christian Boltz
[1] This leads to funny[tm] things like /etc/apparmor.d/cache/ - on
openSUSE it's a symlink to /var/cache/apparmor/ (which is the better
location), but IIRC that's a no-go for Ubuntu because they mount
/var/ later.
--
[Statistik] Schliesslich faelchse ich die ja selbst [...],
kann ihr also trauen... [David Haller in sl-etikette]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
