[Dev] Smack Feature for Vconf

Gaurav Kalra gvkalra at gmail.com
Mon Dec 9 14:39:03 GMT 2013


On Mon, Dec 9, 2013 at 6:41 AM, Schaufler, Casey
<casey.schaufler at intel.com> wrote:
>> -----Original Message-----
>> From: Gaurav Kalra [mailto:gvkalra at gmail.com]
>> Sent: Sunday, December 08, 2013 2:04 AM
>> To: Schaufler, Casey
>> Cc: dev at lists.tizen.org; prasanth.k at samsung.com
>> Subject: Re: [Dev] Smack Feature for Vconf
>>
>> On Sun, Dec 8, 2013 at 1:53 AM, Schaufler, Casey
>> <casey.schaufler at intel.com> wrote:
>> > [...]
>> >> For Tizen 3 the correct way to set the Smack label of a file will be
>> >> in the manifest, using an assign:
>> >>
>> >> <assign>
>> >>     <filesystem path="/a/b/c" label="Appropriate::Label" /> </assign>
>> >>
>> > [...]
>> >
>> > Just my few cents:
>> > 1. vconftool abstracts the storage location of vconf keys.
>> >
>> > During the process of configuring the system precision and correctness
>> > is of paramount concern. Abstraction tends to make it difficult to be
>> precise.
>> > During the configuration process abstraction often makes it difficult
>> > to track down inconsistencies and exceptional behaviors.
>> >
>>
>> Agreed.
>> And I support smack permissions to be set by only manifest files.
>>
>> >
>> > 2. AFAIK manifest doesn't allow relative filepaths while setting smack
>> > permissions (please correct me if wrong)
>> >
>> > Why would you want to use a relative pathname during the installation
>> > process? During the installation process it is important that you know
>> > where things really are.
>> >
>>
>> From a package maintainers perspective current situation while dealing with
>> setting vconf keys is something like this:
>>
>> vconftool set
>> <TYPE_OF_KEY>
>> <DATABASE or FILE or MEMORY> followed by <RELATIVE PATH OF KEY>
>> <INITIAL VALUE OF KEY> <SMACK PERMISSIONS>
>>
>> And it's upto vconftool to decide the absolute location of the key based upon
>> DATABASE / FILE / MEMORY prefixes.
>>
>> e.g. maintainer only specifies "memory/telephony/imei" and vconftool
>> creates the key at "/var/run/memory/telephony/imei"
>>
>>
>> Now, when we remove "-s" option of vconftool, the package maintainer
>> needs to do as follows:
>>
>> vconftool set
>> <TYPE_OF_KEY>
>> <DATABASE or FILE or MEMORY> followed by <RELATIVE PATH OF KEY>
>> <INITIAL VALUE OF KEY>
>>
>> +
>>
>> <assign>
>> <filesystem path="absolute_path_of_vconf_key" label="Appropriate::Label"
>> /> </assign>
>>
>> That means paths decided by vconftool needs to be known (and hard
>> coded) by the package maintainer (what if it is changed later ?).
>
> Yes. This is correct. I submit that this is a good thing. Developers who don't understand the environment in which they are developing are at a serious disadvantage. It makes it very difficult for them to contribute to the system beyond the niche they are working on.
>
>


To draw an analogy, %{_bindir}/foobar is preferred over /usr/bin/foobar.
This keeps the system configurable.

On similar lines I suggest:
<vconf key="memory/foo/bar" label="Appropriate::Label">
should be preferred over
<filesystem path="/var/run/memory/foor/bar" label="Appropriate::Label">


>> My suggestion instead is to let vconftool (or someone else) decide the actual
>> paths and have something like:
>>
>> <assign>
>> <vconf key="relative_path_of_vconf_key" label="Appropriate::Label" />
>> </assign>
>>
>> Is this what's been targeted ?
>
> At the risk of repeating myself redundantly over and over, I don't believe that abstraction in system programing is a good thing. The developer should know where the file is going and why it goes there. If that changes the developer should know why. It makes the system better.
>
>>
>> > Given above, will it be a good idea to strip off "-s" from vconftool ?
>> >
>> > The '-s' code as implemented is unacceptable.
>>
>> I agree on this also. Manifest is the way to go forward, but my concern is
>> about relative / absolute paths.
>
> For the reasons above, I believe in absolute paths.


I too believe in absolute paths but a syntactic sugar like "<vconf
key="memory/foo/bar" label="Appropriate::Label">" should be provided
because vconftool doesn't allow setting up my own absolute paths.

While creating the key using vconftool, developer is expected to
believe in relative paths but while setting up smack permissions, hir
is expected to believe in absolute paths. This sounds more confusing
to me.

--
Gaurav Kalra
Samsung R&D Institute Bangalore
Tweet it out @gvkalra


More information about the Dev mailing list