Hello,
I've problems with my statusleds plugin. If vdr is not running as root all capabilities are dropped - except the one for setting the system time.
My plugin wants to set the keyboard leds with the ioctl KDSETLED on /dev/console. Unfortunately this ioctl requires one more capability.
Is there any way to get this capability? Should we extend the plugin interface with a possibility for the plugins to specify needed caps?
Greetings, Bernd
Bernd Juraschek wrote:
Hello,
I've problems with my statusleds plugin. If vdr is not running as root all capabilities are dropped - except the one for setting the system time.
My plugin wants to set the keyboard leds with the ioctl KDSETLED on /dev/console. Unfortunately this ioctl requires one more capability.
Is there any way to get this capability? Should we extend the plugin interface with a possibility for the plugins to specify needed caps?
Why not simply document this fact in the installation guide: "The plugin must have write access to /dev/console." This is similar to the dvd or vcd plugin which need read/write access to /dev/dvd resp. /dev/cdrom.
On my machine, I added the vdr user to the cdrom group. For /dev/console, this might be a bit trickier: I would have to add vdr to group tty AND give /dev/console rw-permissions for the group, but that should suffice.
I don't know much about linux capabilities, but my feeling is, that they are meant for things not represented by devices (which use the simpler file-permissions model).
Just my 2 cents,
Why not simply document this fact in the installation guide: "The plugin must have write access to /dev/console." This is similar to the dvd or vcd plugin which need read/write access to /dev/dvd resp. /dev/cdrom.
Hmm - this sounds like a good idea ...
On my machine, I added the vdr user to the cdrom group. For /dev/console, this might be a bit trickier: I would have to add vdr to group tty AND give /dev/console rw-permissions for the group, but that should suffice.
I don't know much about linux capabilities, but my feeling is, that they are meant for things not represented by devices (which use the simpler file-permissions model).
On my system /dev/console has r/w access for anyone but this is not sufficient. I take a look into the kernel sources and there a two ways to get the right to modify terminals with ioctl():
- the modified terminal is the controlling terminal for the process or - the user has the capability to modify terminal settings
What can we do now?
Greetings, Bernd
Bernd Juraschek wrote:
I don't know much about linux capabilities, but my feeling is, that they are meant for things not represented by devices (which use the simpler file-permissions model).
On my system /dev/console has r/w access for anyone but this is not sufficient.
Damn. so much about file-permissions in /dev. :-(
I take a look into the kernel sources and there a two ways to get the right to modify terminals with ioctl():
- the modified terminal is the controlling terminal for the process or
This is reflected by vdr's --terminal option. Are you sure, that you must ioctl /dev/CONSOLE or is any other tty sufficient, must it be a foreground tty or can it be a virtual screen not currently active, a pseudo tty (of screen, sshd, KDE-konsole)? In the case, all that works, I suggest adding a note to your documentation that the user MUST specify the --terminal option of vdr and us stdin/stdout/stderr as file-descriptors for the ioctl.
- the user has the capability to modify terminal settings
The Plugins are loaded long AFTER droping root rights, so I guess there is no safe way for a plugin to request additional permissions/capabilities. Maybe you can ask Klaus to also keep the terminal setting caps, or provide a small patch witch allows the user to do so when compiling vdr (or both ;-) ).
So long,
-
Bernd Juraschek -
Patrick Cernko