chmod 777 /dev/dri/renderD128 - Keeps resetting after reboot.

First_Law_of_Unix

First_Law_of_Unix

Hello,

I am not sure if this is how it should be for FreeBSD in which utilizing the /dev/dri/renderD128 can only be done by root user.
On linux, non root user can utilize the GPU render node renderD128.
I'm working with heavy GPU acceleration tasks and every time I reboot the PC I need to keep re-entering:
su
chmod 777 /dev/dri/renderD128
chmod 777 /dev/dri/card0
exit

So that non root user can utilize the GPU render node renderD128.

I do not like to run programs in root user so that it can utilize the GPU render node renderD128 as root user.

What are some ways to make it permanent in which after doing:
su
chmod 777 /dev/dri/renderD128
chmod 777 /dev/dri/card0
exit

I do not need to reenter it ever again.

Thanks for any advice.
 
Emrion said:
Perhaps, a smarter way is to add group video and render to the user that needs it.
Check the normal permissions and groups of these dev to see if I'm right.
Click to expand...
For sure it's a smarter way.

/dev/dri/card0 and /dev/dri/renderD128 are symlinks to other device nodes, which are read/writable by video group:
Code: 
% ls -l /dev/dri
total 0
lrwxr-xr-x  1 root  wheel   8 Oct 11 07:44 card0@ -> ../drm/0
lrwxr-xr-x  1 root  wheel  10 Oct 11 07:44 renderD128@ -> ../drm/128

% ls -l    /dev/drm/0 /dev/drm/128
crw-rw----  1 root  video   0x88 Oct 11 07:44 /dev/drm/0
crw-rw----  1 root  video  0x108 Oct 11 07:44 /dev/drm/128
 
ljboiler said:
Are these GPU acceleration tasks some custom-built programs? If you trust them not to harm your system, you could just change the owner of those programs to root and set the SUID bit (see chmod(1))
Click to expand...

I was planning to do this, it works well and do trust the program which is doing GPU acceleration tasks, the main program is essentially a 24/7 security surveillance DVR using state of the art artificial intelligence in which majority of the program utilizes GPU for accelerated AI computation and live video transcoding for recording, main objective is to offload CPU as much as possible.

However many have argued against doing it on this forum, even professional programmers on the web. They said to use the SUID implementation only when its absolutely necessary. So I just made a thread and wanted to hear what could be said about it.

And thank you to everyone for providing helpful advice.

I will check implementations for devfs.rules and devfs.conf and also adding group video and render to the user who needs it.
 
Emrion said:
As T-Daemon said, you have just to add your user to video group. There is no render group.

# pw groupmod video -m UserName
Click to expand...

Thank You.

I have tried this before when I first installed the AMD drivers and implemented it again now, seems like it does not work:
$ pw groupmod video -m UserName

Here is the program which requires to access the GPU render node:
$ ./darknet detector demo cfg/coco.data cfg/yolov4-tiny.cfg weights/yolov4-tiny.weights -c 4 -i 0

This is what is returned:

failed to open /dev/dri/renderD128: Permission denied
failed to open /dev/dri/renderD128: Permission denied
opencl_init: Could not get device IDs.

Using terminal.

Thanks.

Edit:

Alright so I logged in as root and the following which solved my issue:

nano /etc/devfs.conf

I then added the following texts to the devfs.conf file:

# Allow a user in the wheel group to query the /dev/dri/renderD128 DRI GPU render node:
perm /dev/dri/card0 0666

save it.

Then did:

$ pw groupmod wheel -m user_name
$ pw groupmod operator -m user_name
$ pw groupmod video -m user_name
$ exit


and reboot.

Now logged in as a normal user, I can run the program utilizing the DRI node as root user without getting permission errors.
 
Last edited:
Hello, thank you for the reply.

Yes, I do know how permissions work. This is what I need. I'm not aware of the full details for the perm code 0666, but I think this is good since it seems like anything can use the DRI node since I need all my apps to use it without going through the headaches of setting permissions again or what not.
The security is good enough, since with my testing, only the user set into the correct group can utilize the DRI node.

The workstation I use with these parameters are not my true personal computer. It is just a workstation for testing and programming code and having too strict desktop environment makes the work not too productive. On my personal PC I would keep the DRI to be used only by root user.
 
First_Law_of_Unix said:
I'm not aware of the full details for the perm code 0666
Click to expand...
Then you don't know how permissions work. 6 = read/write, and you've given the owner, group and others write access. You should set it to 0660, so only the owner and the group have write access. Then the group membership makes sense. If you give others write access there's no need for any group membership anymore because everyone will have write access.

docs.freebsd.org

Chapter 3. FreeBSD Basics

Basic commands and functionality of the FreeBSD operating system
docs.freebsd.org docs.freebsd.org
 
Alain De Vos said:
SirDice you are right, but i sacrifice security and give more priviliges, just because it makes my life easier.
Click to expand...
Sure, but then adding the user to a whole bunch of groups is pretty useless because you already have the access through the others permissions.
 
SirDice said:
Then you don't know how permissions work. 6 = read/write, and you've given the owner, group and others write access. You should set it to 0660, so only the owner and the group have write access. Then the group membership makes sense. If you give others write access there's no need for any group membership anymore because everyone will have write access.

docs.freebsd.org

Chapter 3. FreeBSD Basics

Basic commands and functionality of the FreeBSD operating system
docs.freebsd.org docs.freebsd.org
Click to expand...
Thank you, will keep this in mind.
 
Alain De Vos said:
SirDice you are right, but i sacrifice security and give more priviliges, just because it makes my life easier.
Mostly i use 0660 , eg "nothing for other".
Click to expand...
I also assume the same, only for prototyping and development boxes, on a real production box I would set the privileges in most strict settings...
 
First_Law_of_Unix said:
I also assume the same, only for prototyping and development boxes
Click to expand...
It's a bad habit to get into. I see this happening at $DAYJOB too. Yeah, it's just for test (chmod 777 somethings) to see if it would work or not. No, bad test. So what happens when they run into a permission issue on a production server? Yes, chmod 777, because that's the only thing they know how to solve it. It works again, then leave it as is, because they never learned to fix that issue properly. And I get to clean that crap up after yet another scathing security audit or pentest.
 
You must log in or register to reply here.
Back
Top