Re: [PATCH v2] APPARMOR: add sid to profile mapping and sid recycling

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: John Johansen
Date: Tuesday, December 7, 2010 - 2:29 pm

On 11/30/2010 01:56 AM, wzt.wzt@gmail.com wrote:
why here instead of in include/sid.h ?


Hrmm, nothing wrong here, I have just preferred keeping the details of a units
init with in the unit.  So in this case I would create a new fn in sid.c and
just call the fn from here.

Of course that is just my preference, its not a requirement.


Hrmm, no.  I really can't see the justification here for recreating a special
case of aa_alloc_profile.  Yes allocating a name just to free it again is a pita
but as more features get added its going to be more and more important to have
a single init point for the profile.

perhaps a second patch passing and extra parameter to aa_alloc_profile indicating
that the name can be directly assigned instead of duplicated

extra trailing space
  
Hrmmm, as far as I can see this should never happen.  If the profile is successfully created it
has a sid allocated.  So something is very wrong if this condition happens

In this case I would do
	BUG_ON(aa_free_sid(profile->sid) == -1);

hrmm are two invalid values required.  I don't really care which is used as an
invalid value but I can't see a reason to have two values in the current code.

Also an invalid value of -1 when the type is u32 makes me twitch.  Yes I know
it can be done, but it would be cleaner to setup a define

#define invalid_sid ((u32) -1)

or change the sids type.

can be marked as __init

can be marked as __init

having the ability to tear down and free memory is nice but are
we ever going to use it?   Once the module is inited we never
actually never shutdown/cleanup the global structures.

@new_profile: ...

how about returning -ENOENT?
hrmm, I think I'm okay with this, I need to make another pass to make sure
that this is cosher with profile references and life cycles.


A few more general points (nothing that needs to be attended to immediately
but could be done in the future).
- at some point in the future sids will have to be able to map to either
  a single profile or a list of profiles.
  I don't think there is anything to do now, but it is something to keep
  in mind.
- It would be nice if the sid table could be more dynamic.  Maybe be
  allocated in chunks instead of all at once
- it might be worth keeping a small (size limited) queue of the most recently
  freed sids, so that you can skip the free, alloc, search, when some sids
  have been freed recently

thanks Zhitong

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH v2] APPARMOR: add sid to profile mapping and si ..., John Johansen, (Tue Dec 7, 2:29 pm)