From: Joshua Brindle <jbrindle_at_tresys.com>
Date: Wed, 23 Nov 2005 14:46:19 -0500

Ivan Gyurdiev wrote:
>

>>> I'm starting to question the need for this interface at all... it's 
>>> an interface for a very narrow user base - genhomedircon... which is 
>>> probably a mistake. I would prefer genhomedircon to find its way into 
>>> libsemanage, which is its only user (does it have another one?). 
>>
>> the semanage tool Dan is writing could use it, to determine if a level 
>> should be set, or it could just rely on getting an error back if you 
>> try to set a level and it is a non mls system.

>
> I'm confused... it needs genhomedircon, and not the library?
>

which interface were you refering to? the semanage tool will need to modify most entry types.

>>> there would be no reason for an external interface for default roles 
>>> and hacks to move genhomedircon before one lock is released, and 
>>> after the other is released, and things like that would not be 
>>> necessary. 
>>
>> genhomedircon is a reader, it is using resources outside of the module 
>> store and is not confined to the sandbox. I don't know that it should 
>> be inside the transaction.

>
> Readers should be inside the transaction to guard against race
> condition. You mentioned commit numbers, and I pointed out I don't use
> them yet - and I don't see how they're a win over using a transaction.
>

You should be, this should certainly be a higher priority to fix than reimplementing a working tool.

>>> Genhomedircon encapsulates an implementation detail of user/seuser 
>>> updates. Is there another reason for it being outside libsemanage, 
>>> other than python being easy to work with?
>>>
>> Mainly that its already done and works. We really do have higher 
>> priority things than reimplementing genhomedircon in C to put in 
>> libsemanage.

>
> Maybe... unless it results in libsemanage APIs that are going to be
> removed later. What's your opinion of what this API should look like -
> opaque object that can be expanded for other data (aux_info), or prefix
> only? How would system vs local work - see other questions in the thread.
>
>

this is the reason semanage_user, etc are opaque. you can add a field and accessor to it without interupting anything else. Therefore you should just export a new piece of data from whatever type needs it, and if something else is needed later the same thing can be done.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Received on Wed 23 Nov 2005 - 14:48:21 EST