> Why have a file per user?

I thought that's what you were suggesting - store per user contexts
in their own file, and then re-generate the end result from that.

Alternatively it could all be in one big file, but then I 
don't have any information what came from where. Regenerating
the regexps from the template (1) requires delete
to have the same information as add, which is otherwise
not necessary. Currently that consists of the home dirs, but
in the future it could consist of other stuff too, and
(2) requires me to match every line in homedirs against
every template expression, which just seems unnecessary.

> > > Can you give an overview of these patches - what you are trying to
> > accomplish in
> > > more detail and the design?
> > 
> > Well I was trying to accomplish the following:
> > 
> > - add -R flag to useradd, and have it automatically validate
> > and add user roles, and generate user contexts (and add user to running
> > policy)
> > 
> > - have userdel undo the above
> > 
> > - have usermod modify user roles in file and policy, and on default
> > role change, recreate the contexts.
> > 
> 
> We were planning on deprecating seuser because of general bit rot. It does do
> all of this (through wrappers, etc) so if any of that code is useful feel free
> to grab it (it's GPL).

Is seuser a library or a command line tool? I want to write a library..

I'm not sure how much help I need, since I have already made sufficient
progress on this - I can successfully complete add, and 
then delete and modify shouldn't be all that hard, once
I decide what to do about finding the user contexts.

I still need to add more validation, and rollback...

> > - expose the net_contexts file through the libsepol library
> > 
> 
> Changes or just query?

Changes, eventually.
Actually Dan's telling me that for starters I need to
get net_contexts.local set up, but I'm looking forward
to manipulating this file automatically in the future.

> > In addition I am doing the following changes, which affect you:
> > 
> > - modify all libsepol functions to work via policydb and
> > not (data,len) image (because there's no reason to policydb_read
> > on each function call...)
> > 
> 
> Definitely a good idea.

it still takes 4 seconds for useradd to load the policy.
It's awfully slow.... that's 2x policydb_read, because of
the verify-after-write. 

> > - make policydb an opaque data structure to address the
> > exposure created above
> > 
> 
> Great - and then various helper functions can be added incrementally until there
> is a full API.

Right....however I'm making an incompatible change here.
policydb_destroy has been changed to free the policy, which
requires all policydb structures to be created on the heap 
via policydb_create. I have to fix existing users.

> 
> Hmm . . . why have the records so directly tied to files? Seems like the API
> needs to be a little higher level to actually make it work with something like
> an LDAP backend.

They are not... the record structure itself is located in a separate 
file. The create/destroy/set/get methods are packaged with the record.
The record thing isn't much more than a wrapper around a struct.
I don't use internal selinux datums for this, because I want to stay
close to the format used in the outside world (human readable strings).

The parse/print methods are packaged separately, because they are
file dependent. The record_iterate and record_modify_file are obviously
file dependent. Someone can implement the top level functions
in a different way with a different backend. 

> Thanks for the overview - it has clarified some things for me. I'm trying to get
> a handle on how we want things to look in the future. One concern is that this
> api uses libsepol - e.g. it makes it clear to the caller that it is manipulating
> a policy file. We have been discussing / imagining an API that will be forward
> portable to the policy server where the act of adding a user might involve and
> IPC call to the server and be significantly more abstract than a policy
> manipulation. 

Take a look at attached headers, and see if you can make suggestions.
Yes, I know I should probably prefix those records with something sane,
but I haven't done that yet.

I'm considering removing the user/type/role/mls fields from 
port and fscon, and making that part of the common context_record.h
instead.

> Not certain, therefore, that libsepol is the correct place for the
> client api (e.g. the one used by useradd). Thoughts?

It's difficult to me to write forward portable code, when I don't
know the future :)