> -----Original Message----- > From: Gaurav Kalra [mailto:[email protected]] > Sent: Sunday, December 08, 2013 2:04 AM > To: Schaufler, Casey > Cc: [email protected]; [email protected] > Subject: Re: [Dev] Smack Feature for Vconf > > On Sun, Dec 8, 2013 at 1:53 AM, Schaufler, Casey > <[email protected]> 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
