[Dev] Smack Feature for Vconf

Schaufler, Casey casey.schaufler at intel.com
Mon Dec 9 01:11:54 GMT 2013


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

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

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


More information about the Dev mailing list