FS#31586 - [libcec] libcec does not work for normal users

Attached to Project: Community Packages
Opened by Dan Andresan (forumache) - Monday, 17 September 2012, 21:04 GMT
Last edited by Ike Devolder (BlackEagle) - Sunday, 21 October 2012, 18:26 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ike Devolder (BlackEagle)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
libcec, for Pulse8 HDMI CEC adapter, does not work for normal users.
It tries to lock the serial port (USB actually) using lockdev, but instead of
creating files in /run/lock/lockdev (owned by root:lock) it tries to create them in /run/lock (owned by root:root), without being able to. As such, the user is forced to change permissions of /run/lock to 777 (!!).

Additional info:
* package version(s)
libcec 1.8.1-1
* config and/or log files etc.
I attached an strace file for the command: "cec-client -l".
Grep for /var/lock.

Steps to reproduce:
1. install libcec
2. run "cec-client -l"
3. Error messages: error opening /devttyACM0, couldn't lock the serial port
4. ls -l /dev/ttyACM0
5. see that it is owned by root:uucp, crw-rw----
6. ok, add the current user to uucp group, this should fix it
7. no, still no fix, although it can open it now (I guess), it is not able to lock it
8. strace cec-client -l
9. see that it tries to create a file in /var/lock (actually /run/lock since /var is a symlink to /run) and gets permission denied
10. yes, of course, because /run/lock is root:root 755 and we are a normal user...
11. see that there is another /run/lock/lockdev owned by root:lock
12. there is no point in adding myself to lock, since cec-client will insist in writing to /run/lock (not allowed).
13. as a workaround, I changed permissions on /run/lock and everything works wonderfully (cec-client, but more importantly, XBMC with Pulse8 adapter).
14. still, not happy, libcec should write to /run/lock/lockdev, I will add myself to lock group and the problem will be solved cleanly... instead of me messing with /run/lock permissions

Please fix, more info available on request, I am eager to help.

This task depends upon

Closed by  Ike Devolder (BlackEagle)
Sunday, 21 October 2012, 18:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  libcec uses the correct lockdev now
Comment by Dan Andresan (forumache) - Monday, 17 September 2012, 21:28 GMT
Now, after downloading the sources for libcec, it seems that the problem is not with it (cannot find the /var/lock in the sourcecode), but with lockdev itself.
lockdev is required by only two packages (libcec and schroot).
Comment by Dan Andresan (forumache) - Monday, 08 October 2012, 15:52 GMT
Sorry, I rescind my closure request :(
Although libcec depends on lockdev, it seems that lockdev is actually statically linked.
So the recent fix in lockdev did not fix the problem in libcec.

The incorrect /var/lock is cleary visible in libcec.so:

$ strings /usr/lib/libcec.so.1|grep lock
...
/var/lock


The path is now corrected in lockdev:

$ strings /usr/lib/liblockdev.so.1 |grep lock
...
/run/lock/lockdev

But libcec does not seem to use liblockdev

$ ldd /usr/bin/cec-client
linux-gate.so.1 (0xb7794000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb777f000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7764000)
librt.so.1 => /usr/lib/librt.so.1 (0xb775b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7673000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7656000)
libc.so.6 => /usr/lib/libc.so.6 (0xb74aa000)
/lib/ld-linux.so.2 (0xb7795000)
libm.so.6 => /usr/lib/libm.so.6 (0xb746a000)

Comment by Dan Andresan (forumache) - Monday, 15 October 2012, 10:21 GMT
  • Field changed: Percent Complete (100% → 0%)
Andrea, I requested this to be closed, but later I commented that it should remain open, because libcec does not use lockdev as a dynamic library, it is statically linked.

So, the fix in lockdev does not solve the bug in libcec.

Please see my previous comment, thanks.
Comment by Ike Devolder (BlackEagle) - Monday, 15 October 2012, 11:42 GMT
with libcec 2.0.0 it looks ok, but it needs a rebuild of lockdev

and then we get issues with xbmc since the current stable xbmc does not work with libcec >= 2.0.0
Comment by Ike Devolder (BlackEagle) - Saturday, 20 October 2012, 18:00 GMT
@forumache is libcec any way usable atm, also in combination with xbmc

if it is a pure headache to use we can drop the optdepend from xbmc for now and update libcec
Comment by Dan Andresan (forumache) - Saturday, 20 October 2012, 19:27 GMT
@BlackEagle, no, libcec is not usable because xmbc will display something like "could not connect to Pulse adaptor".
This is because libcec tries to write the lock file to /var/lock and this is owned by root:root.

The workaround (that I use) is to chown /var/lock to root:lock and add the xbmc user to lock group. After that, xbmc will work great.

But this is not the proper workaround (and it is also a potential security risk). The libcec should write, using liblockdev, to /var/lock/lockdev (instead of /var/lock) which already belongs to root:lock. This is what the fixed lockdev library (which is a dependency on libcec) does. But, unfortunately, libcec seems to link liblockdev statically, so the fix in the new lockdev package is not propagated to libcec.

The proper fix in my opinion is to build libcec with the new lockdev package (and, even better, link lockdev dynamically). Of course, this is based on my assumption (based on ldd output) that lockdev is statically linked. Maybe I should set up ABS and verify this assumption.

I have the Pulse8 CEC adapter so I could verify the functionality, but this seems to be a simple problem of writing to the wrong directory.

Many thanks for looking int this,
Dan.
Comment by Ike Devolder (BlackEagle) - Saturday, 20 October 2012, 20:17 GMT
the upcoming build of 1.9.0-2 should fix the issue, 2.0+ will be postponed until i find support for it in the current xbmc 11 or the new xbmc frodo gets released
Comment by Ike Devolder (BlackEagle) - Sunday, 21 October 2012, 18:26 GMT
i have tested it as far as i can and this problem seems fixed

for people wanting the latest libcec i have one in my repository (used for xbmc-git)

Loading...