[Dev] Smack Feature for Vconf

Schaufler, Casey casey.schaufler at intel.com
Mon Dec 9 17:13:29 GMT 2013


> -----Original Message-----
> From: Gaurav Kalra [mailto:gvkalra at gmail.com]
> Sent: Monday, December 09, 2013 6:39 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org; prasanth.k at samsung.com
> Subject: Re: [Dev] Smack Feature for Vconf
> 
> 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">

If I thought that there was something special about vconf keys I might be swayed, but I don't see how they are different from any other data file. If we want to decree a special place for them (we should, BTW) then they can be pre-created and installed using the mechanisms already in the .spec files. 

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

Right. I think that the problem is vconftool. We shouldn't need it. The initial key files should be created when the package is built and installed as part of the package. It should not be done as a post-op.

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


More information about the Dev mailing list