[Dev] Smack Feature for Vconf

Gaurav Kalra gvkalra at gmail.com
Sun Dec 8 10:04:27 GMT 2013


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

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 ?

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

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


More information about the Dev mailing list