Access to devices without console login

[puterboy]

I would like to be able to access various devices (and the programs that use them) remotely when I am not able to log in to the console. For example, if I want to use vlc to stream video from my tv card then I need access to /dev/video1.

I'm just not sure what is the best way to do this. Of course, I could each time use brute force to give myself ownership of the device but that's ugly and it requires root access each time. Also, it needs to be done manually each time since permissions are reset when someone logs in to the console or at reboot.

I'm sure I could also play with the udev scripts to give myself more permanent permission but that too is pretty brute force.

In the past, I wrote a script to put my user name in /var/run/console/console.lock and then ran /sbin/pam_console_apply but that is still a bit of a brute force kluge.

So, I was wondering whether there is a better way, perhaps using the hal acl functionality. I would be interested in how to both give myself fine-grain access to individual devices and also how to give myself blanket console-like access to the devices (as if I were logged in at the console).

I am running FC8.

Thanks!

[puterboy]

Anybody able to help me here or am I just posting in the wrong forum...

[jrummy27]

In my opinion, udev is the best way to do this and this is one of the purposes it is designed for. Writing udev rules is quite simple, and for permissions issues usually can be as short as something like this in /etc/udev/50-udev.rules:

KERNEL=="video1" OWNER="myuser" GROUP="mygroup" MODE="0660"

[puterboy]

Yes and thanks - I am aware of how to do it in udev but my concern is that I am then basically "hardwiring" in a specific owner/group/mode configuration that will overwrite the more general default one. That for example may work for me when I am trying to access the video device remotely, but presumably would screw someone else who later tries to log in from the console.

Based on googling, it seems like the hal/acl stuff may offer the ability to give broader and more granular control but I couldn't find any good writeups at the level of detail I need. Also, before mucking with security stuff, I would like to make sure that I am taking the right approach.

So I was hoping for a more "elegant" and "flexible" approach, but if one doesn't exist, I will probably have to use udev similar to how you suggest.

[jrummy27]

I guess I am not understanding what goal you wish to accomplish...You can't access a device over vnc but can from the terminal as the same user? That shouldn't be. Logging in through vnc gives you the same rights/permissions as logging in locally.

As long as your udev rule gives broader permissions that the original policy then nothing will have a problem. So if owner is root:root and permissions are 600, then if you make it myuser:mygroup 660 nothing that needs access will have a problem.

As far as hal/acl stuff I have no experience with that so can't comment.

[puterboy]

Originally Posted by jrummy27

I guess I am not understanding what goal you wish to accomplish...You can't access a device over vnc but can from the terminal as the same user? That shouldn't be. Logging in through vnc gives you the same rights/permissions as logging in locally.

I was talking about VLC (not VNC). I use VLC to stream multimedia over my lan. I typically access it (to start/stop a stream for example) via ssh. But logging in via ssh does not set console permissions (which I believe is done through some combination of pam and hal/acl stuff)

As long as your udev rule gives broader permissions that the original policy then nothing will have a problem. So if owner is root:root and permissions are 600, then if you make it myuser:mygroup 660 nothing that needs access will have a problem.

True, but I would prefer not to create "broader" permissions if not necessary. On the contrary, I would prefer to be as GRANULAR as possible in granting permissions. Call me paranoid

As far as hal/acl stuff I have no experience with that so can't comment.

Me neither But I truly APPRECIATE your attempt to help me here...

[jrummy27]

I was talking about VLC (not VNC).

My bad, /me reads closer this time and now it makes sense.