On Tue, Jul 5, 2011 at 6:51 PM, Jason alavaliant <[email protected]> wrote: > Hi, > > I've been doing some testing of Eduard Hasenleithner's Intuos4 LED and OLED > patch and have got it mostly working to my satisfaction (support for > wacom-config should be coming in the next few weeks) but one point I'm > unclear on is how best to handle the permissions required to update the oled > images. > > As the patch currently stands you have to be root/have sudo access to run > the command to do the update. That's not so useful when considering > giving access to the ability to end users on the network you maintain who > are devoid of sudo/root permissions. (and not so good for wacom-config > since I sudo'ing the app would rather confuse the settings for other things) > > I'm unclear from the notes I can find as to what the end plan is when the > patch is accepted upstream and people start looking at support in > xsetwacom. Is there some config file I've missed that can be used to set > permissions on sysfs items? or is the plan to just have people sudo > xsetwacom when they need to set an led? I was thinking based on past > experience the most security policy correct setup would be to give the files > you write to a group other than root and group write permissions, you could > then set the users who should have access to update the oleds to be in the > group? It doesn't look like that's the current plan though since the patch > only sets write permissions on the files for the owner (root). > > My current hack I'm using for my users is to search and replace through the > patch to turn S_IWUSR into S_IWOTH which gives easy setting of the oleds via > my code without needing it to run with elevated permissions. I'd rather if > possible find a better supported option so users onside my network don't > have to do patch their modules if they want to set oleds via my code. > > Can anybody more familiar with kernel permission policies etc comment on > which way I should be taking this? > > Thanks for your time > -J
I do not know the long term plan for this as well but I can make some educated guesses. It doesn't make sense to use xsetwacom for this feature unless you add logic directly into xf86-input-wacom that opens the sysfs file and send data itself. If this is done then it will be able to open that device for same reason it can open the root owned /dev/input devices related to tablet. That would solve your problem right there. >From xf86-input-wacom developer viewpoint, It seems a lot of effort for effectively a pass threw service. I'd pursue something like your doing first. For this type of issue, people don't really change the permission of these sysfs though. What I've recently done as a stepping stone for similar problem is to create a utility that does the work of accessing the sysfs and passing data to it. Then I create a sudoer file that gives everyone access to that 1 utility. Its kinda a strange way to work around not having permission control but it does fit in nicely with way people normally do this stuff. If you look at all the GUI's/applets that control sysfs settings, they all seem to have daemons running as root to do the actual access and communicate with GUI using DBUS. The way you register your dbus system service is very similar to that sudoer file (its a security policy). Then your utility becomes a daemon and you tack on some dbus glue between two programs. The applets that control CPU frequency in gnome seem to use PolicyKit to access the sysfs but I couldn't find much info on how to do it that way... and it seemed to me if you use PolicyKit you can get root access but you'll always get a popup window asking for a password for this access. Not something you want to occur at each login. Maybe there is a way to configure that access without popup window? Hope its of some help, Chris ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
