On Thu, Mar 01, 2007 at 10:54:19PM +0300, Nikita V. Youshchenko wrote:
> So a *fix* for this issue could be only inside udev package.
> In all other places, only workarounds are possible.
> And these workarounds do have the following drawbacks.
>
> - if base-passwd will be used as workaround location, this will create a
> situation when changes to default udev configuration files, introducing
> references to new groups or removing references to old ones, will cause
> need of base-files update - which is increased complexity and will cause
> out-of-sync situations;
My opinion is quite the opposite. Decisions like "all scanners should be
owned by the 'scanner' group" are distro-wide policy, and udev is just
one of the possible implementors of such policy. So the policy should
not be in udev (anyone can write an udev replacement any day). In fact,
MAKEDEV _should_ use the same group on a static /dev; how do you want to
enforce that? (Yes, I realize that MAKEDEV does not have the same amount
of information and therefore can not make such fine-grained decisions as
udev).
Also, on my system the udev configuration references 17 groups of which
12 is already present in /usr/share/base-passwd/group.master. I do not
see any reason not to add the remaining 5 and be done with it.
On the other hand, a rule like "the default udev configuration must not
reference any groups not provided by base-passwd" seems quite
reasonable.
> Also, it is unclear what udevd is going to do with non-resolved groups.
> Likely it will create devices with invalid ownership. Won't that introduce
> breakage at unexpected moments? E.g. if a package that actually uses
> device (and creates a group if it does no exist) will be installed and
> used before next reboot.
How is that different from MAKEDEV creating the node with bad ownership
on a static /dev?
> From the other hand, fix at udev level is relatively easy.
> It just should extract a list of referenced groups (and probably users)
> from config files at build time (not at install time, because the talk is
> only groups referenced in default configs), and add several lines to
> postinst to create these groups if they don't exist.
That would be HORRIBLE. We should _NOT_ create any groups
unconditionally just because udev upstream likes them. New groups are
needed only if there are real users of them and udev is _not_ an user.
So udev must not be the entity deciding whether a group should be
created or not; it should first be discussed with the users, then added
to base-passwd and after that it can be used by udev. It's not like
we're going to add random new groups every other day...
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
