Bug 220767 - Many reader will only work with root rights
Many reader will only work with root rights
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ctapi-common (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-26 05:09 EST by Frank Büttner
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-01 10:55:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Büttner 2006-12-26 05:09:05 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.
Comment 1 Ville Skyttä 2006-12-26 05:35:57 EST
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?
Comment 2 Frank Büttner 2006-12-26 05:54:01 EST
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.
Comment 3 Ville Skyttä 2006-12-26 06:09:20 EST
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.
Comment 4 Frank Büttner 2006-12-26 06:49:24 EST
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.
Comment 5 Frank Büttner 2007-07-21 10:42:01 EDT
I call the new group cardusers.
Comment 6 Ville Skyttä 2007-07-21 11:57:22 EDT
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.
Comment 7 Frank Büttner 2007-07-21 12:22:55 EDT
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
Comment 8 Ville Skyttä 2007-07-21 13:14:45 EDT
(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.
Comment 9 Frank Büttner 2007-07-21 14:02:50 EDT
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.
Comment 10 Frank Büttner 2007-07-21 14:04:28 EDT
2.) is needed for user identification via LDAP(Fedora directory server, OpenLDAP).
Comment 11 Ville Skyttä 2007-07-21 14:57:19 EDT
(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?
Comment 12 Frank Büttner 2007-07-21 15:38:28 EDT
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.
Comment 13 Ville Skyttä 2007-07-21 16:46:57 EDT
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.
Comment 14 Frank Büttner 2007-07-22 03:43:38 EDT
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
Comment 15 Ville Skyttä 2007-07-22 04:02:04 EDT
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.
Comment 16 Ville Skyttä 2007-07-22 04:18:17 EDT
(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, ..."
Comment 17 Ignacio Vazquez-Abrams 2007-07-22 05:17:35 EDT
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.
Comment 18 Ville Skyttä 2007-07-22 05:53:49 EDT
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?
Comment 19 Frank Büttner 2007-07-22 06:51:00 EDT
The number self don't' care, but it must be identical on all systems.
Comment 20 Ville Skyttä 2007-07-22 07:33:41 EDT
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 || :
Comment 21 Kostas Georgiou 2007-07-22 10:49:20 EDT
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.
Comment 22 Frank Büttner 2007-07-22 11:38:43 EDT
This is what I say, over month.
Comment 23 Ville Skyttä 2007-07-22 11:45:20 EDT
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.
Comment 24 Fedora Update System 2007-07-23 11:45:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.