Bug 143427

The command line alternative "logprof" provides an argument -m "logmark" which allows the user to specify a "mark" (date string for example) to denote the point to start reading events. This feature is missing from the YaST UI.

[cc:ing apparmor-dev@ for discussion]

Dominic: that helps if they're seperated in time, but if they're commingled in the logs, you get to deal with them all. IMO, logprof and its yast counterpart ought to offer up a list of profiles that have outstanding events that need handling, and then let the user select them one by one to process.

We haven't added this feature because there is a complicating factor that we didn't know how to solve cleanly that is best described through an example:

Consider two programs and profiles, A and B. A execs B, but no execute permission has been granted in A's profile yet. You wish to update B's profile. However, we cannot determine which set of questions to ask about B until the user has made a decision about domain transitions between A and B.

I believe this situation is going to be rare once a system has been deployed, but early in profile generation it is likely any time the sysadmin works on multiple profiles simultaneously.

Perhaps we could do something like ask all the domain transition questions, and _then_ do the filtering down to a specific profile or program; I completely agree that it would be nice to say "I want to fix this specific problem and leave the rest for later."

Thanks Olli

That would be fine. 
As from the user view: the minimum I need is selecting one binary from lots & setting permisisions for this binary only. Yes it will be overriden if this is a doughter process. Though if I'm admin - I should know that. =) If you'll produce a "big-red-warning" :) with example above & then permit selections for this one binary - it'll be enough to make people think a bit & be aware of possibilities. =)
The more clever/adaptive solution may wait more.

I think it definitely makes sense to have it display a list of which profiles currently have unhandled events in the log file and let the user select which ones to ask questions about.

Seth's right that if you launch the app you're interested in from another confined app that doesn't have a related rule, it could hide the execution and potentially be a little confusing, but I think it would work better overall.  (e.g. creating a firefox profile and then launching firefox from a confined gnome-panel process would show changes to the gnome-panel profile, but not changes to the firefox profile until you'd gone through and chosen to add a px rule for firefox to the gnome-panel profile)

I think it probably won't be that hard to fix this, but the thought of making yast interface changes makes me cringe a little.  :)

Closing as LATER but probably rather WONTFIX for ENOTIME. Sorry.

Yes it is a LATER, it didn't make it into 11.0 but there was a lot of under the hood improvements and it is likely to show up in 11.1

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED.

In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(