On Wed, Jul 6, 2011 at 12:37 PM, Chris Bagwell <[email protected]> wrote:
> 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.
>
That seems a sensible way to cover it, didn't think of it going via the
actual X driver rather than xsetwacom accessing sysfs directly.
>
> 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.
>
Yes I'll not be waiting for support in xf86-input-wacom directly, (I'm of
the understanding that such support is many months off and I've got working
code that just needs to be integrated in wacom-config ready right now.)
>
> 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
>
Yes that very helpful thanks, I didn't think of PolicyKit for some reason
but it's certainly worth looking into it. Depending on what capabilities
are available with reference to sysfs it might cover grant accesses to
normal users (some of my coworkers have used it to great success for
transparently enabling networking type permissions for limited accounts)
possibly with the need for a password prompt.
I think dbus and daemons are more work than I want to put into this (plus I
don't trust my code not to make any root daemon a massive security hole)
As a more basic step while integrating the code I've got I think I'll also
look at setting up wacom-config so that if the users running it doesn't have
permissions it will optionally try running
some sort of limited sudo command that just copies the images. I bit
clunkier than I'd like but should allow things to work at a very basic
level.
-J
------------------------------------------------------------------------------
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
