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



## First_Law_of_Unix (Oct 13, 2022)

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.


----------



## gpw928 (Oct 13, 2022)

See devfs.conf(5)


----------



## ljboiler (Oct 13, 2022)

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))


----------



## Alain De Vos (Oct 13, 2022)

Two files to edit in /etc:
devfs.rules
devfs.conf
There are man pages for the two files
In devfs.conf you can put the lines:

```
perm  /dev/dri/renderD128 0777
perm  /dev/dri/card0 0777
```


----------



## Emrion (Oct 13, 2022)

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.


----------



## T-Daemon (Oct 13, 2022)

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.


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:

```
% 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
```


----------



## First_Law_of_Unix (Oct 14, 2022)

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))



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 (Oct 14, 2022)

First_Law_of_Unix said:


> I will check implementations for _*devfs.rules*_ and *devfs.conf *and also adding group video and render to the user who needs it.



As T-Daemon said, you have just to add your user to video group. There is no render group.

`# pw groupmod video -m UserName`


----------



## First_Law_of_Unix (Oct 15, 2022)

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`



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.


----------



## SirDice (Oct 17, 2022)

First_Law_of_Unix said:


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


This gives _everyone_ and _everything_ write access. Do you understand how permissions work?


----------



## First_Law_of_Unix (Oct 18, 2022)

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.


----------



## SirDice (Oct 18, 2022)

First_Law_of_Unix said:


> I'm not aware of the full details for the perm code 0666


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. 









						Chapter 3. FreeBSD Basics
					

Basic commands and functionality of the FreeBSD operating system




					docs.freebsd.org


----------



## Alain De Vos (Oct 18, 2022)

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".


----------



## SirDice (Oct 18, 2022)

Alain De Vos said:


> SirDice you are right, but i sacrifice security and give more priviliges, just because it makes my life easier.


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.


----------



## First_Law_of_Unix (Oct 31, 2022)

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.
> 
> 
> 
> ...


Thank you, will keep this in mind.


----------



## First_Law_of_Unix (Oct 31, 2022)

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".


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...


----------



## SirDice (Oct 31, 2022)

First_Law_of_Unix said:


> I also assume the same, only for prototyping and development boxes


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.


----------

