[Dev] Input device files group

Lukasz Pawelczyk l.pawelczyk at samsung.com
Wed Oct 29 10:14:00 GMT 2014

On wto, 2014-10-28 at 18:07 +0100, Stéphane Desneux wrote:
> > 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.

I didn't say apps, I said applications. Wayland, X.org, those are
applications. In 99% they will be installed, but they are not mandatory
for the platform.

You guys still bring up the argument of different profiles. The
discussion is why the /dev permissions policy should not be in
X.org/wayland. Profiles don't matter here. If the policy were in udev
(or a related package) as I think it should you could still make it
different per profile and let vendor modify it to his own wishes.
If you don't want it directly in udev rpm it could be udev-policy.rpm
with different versions per profile. The are multiple solutions.

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

Of course it is. And I am talking about platform development. You seem
to say that because apps don't touch RPM it justifies having
inconsistent platform. Hmm.

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

IMO it always makes sense to have it in one place _if_ the policy
concerns a global object. input devices are global. They exist
regardless of anything else in userspace.

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

And IMO that is still incorrect.

> So, there's no absolute scheme. We must adjust depending on the devices
> and use cases.

Devices are global. About use cases you have 2 cases:
1. there is one daemon/applications that is interested in the specific
policy regarding a specific object.
2. there are 2 or more (like in wayland/x/security-containers).

In the first case in theory it doesn't matter. But having this globally
increases visibility and you never know when another interested party
shows up.
In the second case you even have to make it global, otherwise every RPM
you install will add another policy that might be incompatible with the
previous creating chaos.

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

I already said, udev. Or some separate udev subpackage (udev-rules,
udev-dev-policy). Or whatever else. Doesn't really matter how you name
it. But it has to be defined globally and be tied with udev with the RPM

Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics

More information about the Dev mailing list