Red Hat Bugzilla – Bug 220767
Many reader will only work with root rights
Last modified: 2007-11-30 17:11:52 EST
Description of problem: Most USB Readers are only work under the root account, because of the udev rules. To fix that problem it will be an good idear to add an new group cardusers(or something like this) to FC. Then all CT-API reader moules can add an udev roule, so that the /dev entry for the reader will be become user=root and group=cardusers. Then all none root users that will access the reader will only have to be an member of the group cardusers. I think this will be cleaner then the old uucp method. Version-Release number of selected component (if applicable): ctapi-common-1.0-3.fc5 The same for FC6,FC-devel.
What /dev entries do these devices create? If they're easily identifiable, instead of udev, pam_console configuration would be better (or perhaps both are needed?). See also bug 202132. Anyway, if a new group for this purpose is added, I think we should look at what other distributions have. I think Debian has "scard", but can't verify that at the moment. The ctapi-common package doesn't sound like the correct one to create this group, because this issue may bite other readers than CT-API ones as well, right?. And to me this sounds like something that should be done in Core now that quite a few smart card packages are there instead of Extras. Bob, thoughts?
In the most cases the reader will be visible at /dev/ttyUSBx with the rights root-root 0660 or root-uucp 0660. But uucp is not an good choice, because it is more for modem/ISDN like devices. So it will be better to add this kind of devices in an extra group. I don't know what the other distros do?? But most do the uucp "hack" or simple set the rights to 666, but this can be an potential security problem. Because the will be shown as an serial device, udev can't assign the right rights without an additional rule file. For example for my cyberjack module the file will look like this: BUS=="usb", SYSFS{idVendor}=="0c4b", GROUP="cyberjack", MODE="660" This is the default from the vendor, but to do it more general GROUP must be changed.
Ok, that sounds like pam_console won't get in the way (nor could it be used if the devices are just generic ones like /dev/ttyUSB*), so this could be done using udev alone.
udev must assign the devices an group, but root and uucp are bad. So every CT-API driver must deliver an udev rule that udev assign the device another group than root/uucp. pam_console can only work with /dev/XXX entry's or? But the /dev/ttyUSBx entry for the reader can't be predetermine, because it depends on the count of other USB devices.
I call the new group cardusers.
Frank, your implementation in 1.0-5 contains many bugs. > +%post groupadd -r -g 300 cardusers||: > + > +%postun groupdel cardusers||: 1) Why do you assume that gid 300 is available? 2) Why does this stuff need a fixed gid in the first place instead of just using a dynamic one? 3) Requires(post): shadow-utils is missing (ditto postun, but see below). 4) The group should not be removed at all, let alone removing it on every package upgrade like your current implementation does. Please fix, see http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups Is "cardusers" used by some other distro for this purpose? See comment 1, I think Debian uses "scard", if there are some group names in use already in other distros for this, it'd be good to follow them.
1) Yes, no package will use it.(I have look at /etc/groups 2) So that it will be on all systems the same GID 3+4) fixed with the name cardusers is mutch cleaner then scard %define GROUPNAME cardusers Requires(pre): shadow-utils %pre getent group %GROUPNAME >/dev/null || groupadd -g 300 -r %GROUPNAME exit 0 and remove the %post %postun stuff
(In reply to comment #7) > 1) Yes, no package will use it.(I have look at /etc/groups No no no. Your /etc/group, and possibly packages in Fedora, that's nowhere near enough. Anyone can have that gid already taken, and you *can't* know it. > 2) So that it will be on all systems the same GID Please explain and provide a use case why that is useful in this case. > the name cardusers is mutch cleaner then scard Matter of opinion. It is also misleading (although scard wouldn't be necessarily any better). A lot of smart cards and smart card software currently in Fedora can be used by regular users without them being in any group.
For the CT-API the user direct access the reader, so an extra group is needed. When using PC/SC you access the reader via an extra daemon.(witch run as root) to in the case you must not be member of an special group. It is only needed for the CT-API interface.
2.) is needed for user identification via LDAP(Fedora directory server, OpenLDAP).
(In reply to comment #9) > For the CT-API the user direct access the reader, so an extra group is needed. Okay, but again, why is the group called misleadingly "cardusers"? "ctapiusers" or just "ctapi" would describe the intent better. (In reply to comment #10) > 2.) is needed for user identification via LDAP(Fedora directory server, OpenLDAP). Sorry, I don't follow. If one uses LDAP and wants the group we're about to create to be stored there, one just stores it there with a gid, then installs ctapi-common. In that case the group we're creating from the ctapi-common package won't be event created because it exists already (in LDAP). So why is a hardcoded static gid mapping required in this package?
ctapiusers is also a good choice.:) to the static gid's: An very simple example. Without static gid's it can happened, that on 2 or more systems the group have differed gid's.(The gid depend only on the order of the install of the rpm packages) But when using systems like LDAP or NIS only gid numbers are used. So on all systems the group must have the same gid, because the group that is named at the udev script that assign the rights and uid/gid to the reader device. Without that it can be happened, that an user can't access the reader, because of the none static mapping he can be assign to an wrong group. On one system the gid of the readergroup can be 200 and on the other it can be 201. But over the LDAP/NIS system the number is 200. And so none user can use the reader on system 2, because the group id can't be mapped to the reader group.
If LDAP/NIS in use, why wouldn't the ctapiusers group be there too? Having users in LDAP/NIS but their groups locally sounds like asking for trouble to me. Anyway, if the sysadmin wants to have a static gid mapping, that can be taken care of by creating the group with the desired ID before installing the package (locally, LDAP, NIS whatever), see http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups And if the group really needs to have a static gid (which I still don't buy), it should probably be taken from the 0-99 range, not 100-499 which is defined for dynamic allocation by LSB at least for uids, but I guess it applies to gids too. The 0-99 range is pretty crowded already.
Because LDAP/NIS will transfer the groups in part's only as numbers and not at names. So an static local gid is needed to get it working. The only thing what must be solved is to find an free gid:) I will register a static one at http://fedoraproject.org/wiki/PackageUserRegistry
I don't use LDAP or NIS, so I can't prove you wrong, but if this is true and LDAP/NIS groups don't actually work sanely without the group being created locally with a static gid, it has effects on the standardization of user/group creation in packages. Nobody has mentioned that during the creation and review of the current draft (URL in comment 13) and I have problems believing everyone would have missed it. This must be discussed and confirmed on the fedora-packaging mailing list before I accept the static mapping in this package. Please post to that list and explain why it is necessary.
(In reply to comment #15) > I don't use LDAP or NIS, so I can't prove you wrong, but if this is true and > LDAP/NIS groups don't actually work sanely without the group being created > locally with a static gid, it has effects [...] To clarify, I meant "...locally with a static gid created by the package's scriptlets, ..."
While authconfig sets up LDAP so that users less than 500 have to exist locally, it makes no such provision for groups (This is an oversight in my eyes, but them's the breaks). Now having said that, I do believe that it merges the groups together so that it DTRT when a group exists only locally.
Note also that AFAIK there's no hard requirement for the ctapiusers group to have a less than 500 gid - that's just something we do if the group is created by a package's scriptlets. If the local sysadmin so desires, he can create it beforehand with a gid of his liking (optionally in LDAP or similar) and things should just work, no?
The number self don't' care, but it must be identical on all systems.
Sorry, nothing I've heard so far tells me that would be the general case. If the site admin wants that for whatever reason, he can arrange that easily by creating the group beforehand with the desired gid. Unless something convinces me otherwise, I'm going to push 1.1-2 which changes the %pre scriptlet to the following and removes %postun early next week. getent group ctapiusers >/dev/null || groupadd -r ctapiusers || :
What guarantee do you have that whatever directory system is in use has been configured when you install the rpm? Or that the network is on during the installation? Or that the directory server didn't have a problem and wasn't accessible during the rpm installation? What if I want to move a system later on to use ldap/NIS do I have to remember that this program needs special treatment and remove the local random gid assignment? What happens when the sysadmin is asked that people should have access to the card reader and realizes that since he hasn't allocated a gid before hand he now has to "correct" some hundreds of machines that have a random gid? Do you want to add in the installation notes for fedora that if you ever plan to use ctapi in a network environment that you should make sure to have the group created beforehand and make sure that during the installation the directory server is accessible? There is a reason why we need system accounts/groups in the local maps with a static allocation and there isn't really any workaround for that.
This is what I say, over month.
Dynamic uid/gid assignment is very usual packaging practice already for a long time, there's nothing new about that, and nothing specific to ctapi-common. There are multiple ways to get static mapping if the admin wants (including ones that don't require directory access during setup), see the draft linked to multiple times in this bug. If you have reservations about that practice, please post to fedora-packaging along with working suggestions how to do things differently and try to get people to accept them. Some have been already posted, none really accepted thus far. This bug is about why ctapi-common would need special treatment and to have a static gid, not a place to discuss general packaging practices.
ctapi-common-1.1-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.