From: Ivan Gyurdiev <ivg2_at_cornell.edu>
Date: Wed, 23 Nov 2005 15:22:32 -0500

>>>> 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.
I was referring to the interface to export a default role for genhomedircon. It's broken right now, but I'm re-writing it as a general "Auxiliary Data" object... but if there is no other auxiliary data than the labeling prefix/defrole, and the only user is genhomedircon, it's not clear whether a new interface should be written.
>>>> 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.
Why would I want to be checking commit numbers in the library client? How would failure be handled - re-try enough times until it works? Why is this better than using a transaction?

>>>> 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.

Speaking of which... this doesn't work as nicely as you say. Semantically this default role/labeling prefix thing belongs in the user record, and not anywhere else. There's no reason for making a new record for "auxiliary data". It's keyed on the user, because it should be in the user record. The only reason I'm considering adding a new record type, is because the policydb backend does not support marking which role is default, and writing functions like iterate() over two different backends simultaneously (file for defrole, policy for other info) is just wrong.... it's an implementation-driven interface, and not the other way around, which I don't like.

--
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 - 15:16:06 EST