Bug 852745 - Unable to run DirectFB as a normal user
Unable to run DirectFB as a normal user
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: directfb (Show other bugs)
17
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
: Reopened
: 857660 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-29 09:23 EDT by Gerry Reno
Modified: 2013-08-01 13:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 13:46:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gerry Reno 2012-08-29 09:23:58 EDT
Description of problem:
Even after fixing permission problems dealing with /dev/tty1 and /dev/fb* one cannot run directfb as a normal user due to continuing errors such as this:
$ dfbinfo

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.5.3 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2010  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2011-08-23 22:08)
(!) DirectFB/fbdev/vt: K_MEDIUMRAW failed!
    --> Operation not permitted
(!) DirectFB/Core: Could not initialize 'system_core' core!
    --> A general initialization error occured
(#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured
$

Version-Release number of selected component (if applicable):
1.5.3-7.fc17

How reproducible:
Always

Steps to Reproduce:
1.Install DirectFB
2.fix permissions on /dev/tty1 and /dev/fb* to allow normal user
3.dfbinfo
  
Actual results:
See description

Expected results:
dfbinfo and all other directfb commands can succeed as normal user

Additional info:
Comment 1 Nicolas Chauvet (kwizart) 2012-09-15 11:46:36 EDT
I'm not aware of any DirectFB documentation that solve this issue by default.
http://directfb.org/downloads/Core/DirectFB-1.5/README

Quoting from "Usage Requirements":
"You can either run all DirectFB applications as root or allow users to access these devices."

So this still requires tweaking according to directfb upstream themselves.
As suggested in the devel mailing list, it might have another way to solve this issue for normal user, but that's a question for upstream directfb.
Comment 2 Gerry Reno 2012-09-15 12:31:31 EDT
This is not an upstream problem.

I've been through this with DirectFB and they have told me that this is a distro issue about getting the proper permissions setup and in place for the user.  And that is distro-specific.

Even when I set the permissions in the udev rules file the permissions do not get setup properly.

Plus even when I set the permissions manually to the correct settings I still get this 

(!) DirectFB/fbdev/vt: K_MEDIUMRAW failed!
    --> Operation not permitted

which has something to do with modes.

These problems are not occurring on other distros.  Just Fedora.

Please reopen this bug.

.
Comment 3 Nicolas Chauvet (kwizart) 2012-09-15 12:45:15 EDT
Quoting "Tom Callaway"
"The core issue behind why dfbinfo doesn't run as a "normal" user is due
to the fact that the Linux kernel requires CAP_SYS_TTY_CONFIG to do any
TTY ioctl() calls. UID 0 (root) has that, but normal users do not. It is
possible to give a binary that capability using the "setcap" command."

The other way not to run as root or to tweak normal user is to add capability support for directfb. That the RFE that need to be filed
Comment 4 Gerry Reno 2012-09-15 13:10:38 EDT
Ok, then why cannot the post_install run the setcap on the binary for directfb?

I don't see this as an enhancement.  The directfb package is broken in Fedora.

.
Comment 5 Nicolas Chauvet (kwizart) 2012-10-11 17:24:23 EDT
*** Bug 857660 has been marked as a duplicate of this bug. ***
Comment 6 Nicolas Chauvet (kwizart) 2012-10-11 17:27:52 EDT
Re-opening, I might have a way to handle this properly with recent RPM
Comment 7 Fedora End Of Life 2013-07-04 02:15:08 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 8 Fedora End Of Life 2013-08-01 13:46:13 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.