Hi there! On Wed, 04 Mar 2009 00:46:19 +0100, Sebastian Reichel wrote: > On Wed, Mar 04, 2009 at 12:02:50AM +0100, Luca Capello wrote: >> Thus, we are faced with a decision: which system group should be set as >> the default for frameworkd access? >> On Debian, the system group should be picked up from the ones the >> base-passwd package installs (Debian Policy §9.2.1 [2]): > > As far as I understand §9.2.1 you are not allowed to edit > /etc/group, but you are allowed to create a new group via postinst > and addgroup. In fact there are some packages doing this (e.g. kvm).
Your interpretation is correct, and indeed my words were intentionally
stronger than reality, read below why.
>> However, since frameworkd depends on D-Bus, the installation of the
>> latter creates another system group: messagebus
And this already confirmed your interpretation of the Policy §9.2.1 ;-)
> In my opinion the framework should get its own group. All the other
> groups are meant only for parts of the framework (e.g. dialout),
> others are to powerful (e.g. root). If we have a group just for
> framework we won't conflict with any other meanings of system group
> entries.
If we accept this solution, at installation time frameworkd will create
a group in the 100-199 range, as per Policy §9.2.2:
100-999:
Dynamically allocated system users and groups. Packages which need a
user or group, but can have this user or group allocated dynamically
and differently on each system, should use adduser --system to
create the group and/or user. adduser will check for the existence
of the user or group, and if necessary choose an unused id based on
the ranges specified in adduser.conf.
The name should be self-explicative, but fso-frameworkd seems a bit too
long to me, maybe smartphone (the same length as messagebus)?
> Another option would be to split the functionality, so that dialout
> group is allowed to use the dial functions, but nothing else, ...
> But IMHO this way is to much work for developers and users.
While I agree, IMHO this should be the preferred solution, because it
allows by default a more finer right granting. However, I would go with
this solution only if upstream does it as well, not only because of the
burden it causes, but because I do not want Debian to diverge from
upstream.
BTW, this is why I gave a stronger interpretation of Policy §9.2.1,
since I would prefer to reuse existing system groups whenever it is
possible.
Thx, bye,
Gismo / Luca
pgp86eqTb4YoV.pgp
Description: PGP signature
_______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
