<div class="gmail_quote">On Fri, Feb 4, 2011 at 12:26 PM, Martin Langhoff <span dir="ltr"><<a href="mailto:martin@laptop.org" target="_blank">martin@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Fri, Feb 4, 2011 at 11:30 AM, Rich Mattes <<a href="mailto:richmattes@gmail.com" target="_blank">richmattes@gmail.com</a>> wrote:<br>
> The maintainence thing could be eased somewhat by creating a robotics group<br>
<br>
</div>Yes -- it can be a package where all robotis-and-related packagers get<br>
access -- not sure if FAS does "group accounts".<br>
<div><br></div></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
> There's a lot of different ways to access devices, so one solution probably<br>
> isn't going to work. For example, the Arduino package now ships with a<br>
> policykit policy and a launcher that checks to see if your user is in the<br>
> requsite dialout and lock groups[1]<br>
<br>
</div>That is interesting but very weird. As a user, why would I need to<br>
call an admin? Fedora and other distros are consolidating on the view<br>
that "user at the console" is the important criteria.<br></blockquote><div><br>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. <br>
<br>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.<br>
<br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> You can get by with a udev rule that sets the<br>
> camera to 0666.<br>
<br>
</div>Um. I don't think 0666 access mode is a good idea.<br>
<div><div></div><div><br>
<br></div></div></blockquote><div><br>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.<br>
<br><br>Rich<br>
</div></div>