Background:
OS is Fedora Core 1
Hardware is ATI TV Wonder VE
Software is tvtime 0.9.12
The Goal: To allow all the users of the machine (myself and two other members of the household) to watch tv without having to a) be root, or b) execute a separate command after tvtime exits to kill the audio.

(Snipped) Contents of /etc/modules.conf:
options bttv card=64
options tuner type=2
post-install bttv insmod tuner
post-remove bttv /sbin/rmmod -r bttv

I have the same issue as this post:

And have implemented a similar fix. This is the contents of the /usr/bin/run-tvtime file:
#!/bin/sh
tvtime
/sbin/modprobe -r bttv

The problem is that I dont want to run the tvtime app as root, and when I run it as a regular user, I get issues with modprobe. The run-tvtime script outputs on exit:
Thank you for using tvtime.
bttv: Operation not permitted
bttv: Device or resource busy

So the question is: how do I kill the audio as a non-root user?
Thanks.

Dani AI

Generated

A succinct diagnosis and two practical fixes that match the discussion by , and .

The root cause: unloading the bttv kernel module (or otherwise releasing the card) requires root, so a normal user cannot run the existing cleanup step after tvtime exits. Giving full root rights is unsafe; the goal is to grant only the minimum privilege needed or to remove the need for module removal entirely.

Option A — minimal, safe sudo for module removal

  • Create a local group (for example tvusers) and put household accounts in it.
  • Allow that group to run only the specific module-remove command via visudo. Example (add one line to sudoers):
    %tvusers ALL=(root) NOPASSWD: /sbin/modprobe -r bttv
  • Change the tv wrapper so it calls the module removal with sudo on exit; use a signal trap so the cleanup runs on normal exit or interruption. This keeps privileges tightly scoped and auditable. This follows 's suggestion to expose only the needed modprobe action rather than giving wide modprobe/rmmod powers or full wheel access.

Option B — avoid needing module unload

  • Ensure audio and video device nodes are accessible to non-root via group membership or udev rules. Typical steps: add users to the audio group and create udev rules that set group/mode on the video and sound nodes, for example:
    SUBSYSTEM=="sound", KERNEL=="dsp*", GROUP="audio", MODE="0660"
    SUBSYSTEM=="video4linux", KERNEL=="video*", GROUP="tvusers", MODE="0660"
  • This is the approach hinted at by (use permissions/udev rather than chattr). Note that some capture cards still hold resources until the module is unloaded; in those cases Option A is the reliable fix.

Cautions

  • Do not add household users to wheel or give broad sudo rights. Use visudo and full absolute paths. Test the sudoers entry and wrapper as root first to confirm correct behavior before rolling it out.

Recommended Answers

All 4 Replies

So the question is: how do I kill the audio as a non-root user?
Thanks.

Did you set the proper permissions as the other post explained? Have you tried doing chattr on the audio device (making it executable by everyone)?

You could also install and configure sudo so every user in group wheel can run commands without a password using sudo command (just make sure the users actually belong to group wheel.)

I've never came across this issue, so I don't have a working fix for it (I also don't use RedHat/Fedora) so I don't know all the specifics regarding this, but maybe one of these suggestions helps...

Adding the users to the wheel group is the only thing I havent tried, and should only use that as a last resort, as I dont want to allow an accidental: $ sudo rm -Rf

Thanks for the reply.

When you configure sudo, you can specify which commands they can run so that won't happen.

Can you specify 'modprobe -r bttv' or just 'modprobe' though in the sudoers file? If you can have any user in a 'tvusers' group to be able to 'modprobe -r bttv' using sudo, that would be your safest bet. (I think.) I'm sure you wouldn't want to have everyone be able to run 'modprobe <any module>'. For obvious reasons. :) Even if you are the only user of the machine, it just isn't good practice.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.