On 28/10/2014 17:23, Lukasz Pawelczyk wrote: > On wto, 2014-10-28 at 14:51 +0100, Stéphane Desneux wrote: > >> Also, I'm not sure that the rules for defining the permissions on such >> devices should be global.
By 'global' I only meant 'enforced for any tizen profile'. > Because: > > 1. The security policy is global and it's not to applications to define > that. You have 2 packages that write potentially conflicting entries to > the same file now (udev input rules). You might as well introduce a > third that does something completely different. The security policy is certainly not defined by apps, but a hardware vendor must be able to tweak the security on his platform according to its specificness. Making some restrictions for Tizen:IVI platforms is not the same as restrictions for Tizen:Mobile. Some will be common to both, some will be specific. > Not to mention that this is so wrong on the RPM/filesystem consistency > level. The files should be provided by RPM and installed together with > the package, not created by post scripts. That's why there are config.d > directories in the first place. Now you can't even see who added this > entry and why. Every script can do as he wishes. A malicious app could > add another entry to the file and rpm --verify wouldn't catch that. I agree that the rules must be installed properly from a clean and identified RPM (no post scripts). BUT for Tizen 3, I think that webapps or native apps won't be available as RPMs: you'll only have choice on wgt, tpk or xpk. RPM is reserved for platform development. So, no worries on this point. > 2. Because you might have packages on much lower level then X/wayland. I > already gave examples. And those could be used on headless installations > and want to rely on such permissions (which wouldn't exist without > X/wayland installed). > > Security containers is a live example. If we have some use cases that show that a device is shared across multiple software components, it makes sense to define the rule only in one location. But take the list of udev rules in /lib/udev/rules.d: you'll see some rules coming from systemd and others coming from the main package that will use a given device: for example, alsa-utils or bluez. So, there's no absolute scheme. We must adjust depending on the devices and use cases. >> And currently, you'll notice that every >> profile is free to define the permissions as needed (because >> weston-common or x11-common are packages specific to Tizen:Common, not >> supposed to be inherited directly in a Tizen profile. >> >> Why not specifying the input rules where the 'input' group is defined ? > > It only means that the input group is defined in the wrong place. What's your suggestion for a better place ? Best regards, Stéphane _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
