On Fri, Feb 4, 2011 at 12:26 PM, Martin Langhoff <martin@xxxxxxxxxx> wrote:
librxtx needs to write lockfiles to /var/lock/lockdev, which is owned by the group "lock". The /dev/ttyACM* and /dev/ttyUSB* files are all owned by "dialout" by default. The original Arduinos used an of-the-shelf FTDI chip, so it probably wouldn't have been a great idea to ship a udev rule re-assinging permissions based on vid/pid (i don't know if they had any other unique attributes). The new arduinos have their own vid/pid, but you still have to worry about backwards compatibility for FTDI boards. Udev rules would only get you around the device node being owned by dialout, write access to lock is still a problem.
If you're the "user at the console" on a single-user computer, you're probably the admin to begin with. And if your admin knows that he needs to support users accessing serial ports, he might add users to the correct groups ahead of time. I can't think of a better way to go about it, my knowledge of the *Kit frameworks is minimal. I'll note that the prompt indicating which groups you need to be a member of is a giant leap forward from the upstream behavior of failing with a cryptic error message.
Then set the GROUP to "users" or "video" and use 0660? I'm pretty sure all these robotics devices really need are the same permissions any webcam would have(rw), and the people making these libraries generally aren't security experts.
Rich
On Fri, Feb 4, 2011 at 11:30 AM, Rich Mattes <richmattes@xxxxxxxxx> wrote:Yes -- it can be a package where all robotis-and-related packagers get
> The maintainence thing could be eased somewhat by creating a robotics group
access -- not sure if FAS does "group accounts".
Right, I was thinking of the psuedo-accounts you can InitialCC in pkgdb to forward commit messages and such. I guess you'd still have to grant acls individually to such a package.
> There's a lot of different ways to access devices, so one solution probablyThat is interesting but very weird. As a user, why would I need to
> isn't going to work. For example, the Arduino package now ships with a
> policykit policy and a launcher that checks to see if your user is in the
> requsite dialout and lock groups[1]
call an admin? Fedora and other distros are consolidating on the view
that "user at the console" is the important criteria.
librxtx needs to write lockfiles to /var/lock/lockdev, which is owned by the group "lock". The /dev/ttyACM* and /dev/ttyUSB* files are all owned by "dialout" by default. The original Arduinos used an of-the-shelf FTDI chip, so it probably wouldn't have been a great idea to ship a udev rule re-assinging permissions based on vid/pid (i don't know if they had any other unique attributes). The new arduinos have their own vid/pid, but you still have to worry about backwards compatibility for FTDI boards. Udev rules would only get you around the device node being owned by dialout, write access to lock is still a problem.
If you're the "user at the console" on a single-user computer, you're probably the admin to begin with. And if your admin knows that he needs to support users accessing serial ports, he might add users to the correct groups ahead of time. I can't think of a better way to go about it, my knowledge of the *Kit frameworks is minimal. I'll note that the prompt indicating which groups you need to be a member of is a giant leap forward from the upstream behavior of failing with a cryptic error message.
Um. I don't think 0666 access mode is a good idea.
> You can get by with a udev rule that sets the
> camera to 0666.
Then set the GROUP to "users" or "video" and use 0660? I'm pretty sure all these robotics devices really need are the same permissions any webcam would have(rw), and the people making these libraries generally aren't security experts.
Rich
_______________________________________________ robotics mailing list robotics@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/robotics
