aberrate_junior_beatnik (he/him) @ aberrate_junior_beatnik @midwest.social

Posts

2

Comments

336

Joined

2 yr. ago

Ok, so I did some testing locally.

Assuming podman is running as user user, which has a primary group gid 1000, the default /etc/subgid will look like:

    
...
user:100000:65536
...

  

Running podman run --rm -it busybox cat /proc/self/gid_map with this /etc/subgid the output is going to look like:

    
0       1000          1
1     100000      65536 

  

Which means that if you bind mount a volume in and create a file with gid 0, it will have gid 1000 on the host. Subsequent gids will map to 100000,100001, etc. The group video, which should be gid 44, will map to 100043. So one option you have would be to add 100043 (or whatever gid 44 gets mapped to, if your /etc/subgid is different) to the acl of /dev/dri/cardX. Then if your plex user has group video in the container, you should be golden. No need to even have --group-add=keep-groups. Even the user running podman wouldn't need to be in group video on the host.

This is probably what you should do, because the following will change the behavior of every other container the user runs. But since I spent time hunting it down, I'm going to post the rest of this anyway:

As it stands, your container will only have access to the mapped gids above. If you want to get group 44 in your container to map to group 44 on the host, some trickery will be necessary. First, you will have to change /etc/subgid from the above to

    
...
user:44:1
user:100000:65535
...

  

Changing the count on the second line (65536->65535) isn't strictly necessary, but in my testing podman did not like having uneven numbers of gids and uids. Also, the order doesn't matter, you could switch the order of the lines, but podman is always going to interpret it in the order of the host gids. Finally, I had to reboot for the change here to register. There's probably a way to do it otherwise, but logging out & back in didn't do it, and neither did systemctl daemon-reload, so ¯(ツ)/¯

After this change, podman run --rm -it busybox cat /proc/self/gid_map will output something like:

    
0       1000          1
1         44          1
2     100000      65535

  

Ok, so now we have access to the host's group 44, but it's mapped to the container's group 1. That's not very useful, since gid 1 is traditionally the daemon group, which is used for other stuff. So here's where --gidmap enters the picture and it gets confusing. With rootless podman, --gidmap does not take the format {container-id}:{host-id}:{count}. It takes the format {final-id}:{initial-id}:{count}. So if we want to map to the host's id 44, we actually need to map to id 1, which then gets mapped to 44. So here's the command:

podman run --gidmap 0:0:1 --gidmap 44:1:1 --gidmap 1:2:43 --gidmap 45:45:65492 --rm -it busybox cat /proc/self/gid_map

Which then should output:

    
 0          0          1
44          1          1
 1          2         43
45         45      65492

  

Makes perfect sense, right? Well, it does make sense, but it's (at least to me) confusing. What podman does is create a second, nested user namespace, and uses that to make the map. So nested 0 maps to initial 0 which maps to host 1000. Nested 44 maps to initial 1 which maps to host 44. Nested 1 maps to initial 2 which maps to host 100000. Nested 45 maps to initial 45 which maps to host 100044. And so on. So now you should be able to do

    
rm -f fake-dri; touch fake-dri; chgrp video fake-dri; chmod 660 fake-dri
podman run --gidmap 0:0:1 --gidmap 44:1:1 --gidmap 1:2:43 --gidmap 45:45:65492 --mount type=bind,src=$(pwd)/fake-dri,dst=/dev/dri --rm -it busybox sh -c 'echo I can write to /dev/dri > /dev/dri'
cat fake-dri

  

And it should output I can write to /dev/dri. I didn't actually test it with plex, but if the issue really is permissions on /dev/dri/cardX, this should work.

You might need to also add --gidmap=n:{video_gid}:1, otherwise the host video group won't have a matching group in the container's user namespace. n can be any number you pick, so long as it doesn't clash with an existing gid in the container. Unsure if --group-add=keep-groups does this already. You can check /proc/self/gid_map to see what is already being mapped.

Of course the container user will need group n (from the gidmap flag above) either as primary or in the supplementary groups.

[edit: I wrote this at 3am on my phone, and I misunderstood how the --gidmap flag works. This code won't work, but I think the diagnosis is correct: there's no mapping from the host's video group to the container's user namespace, see my other comment in reply to OP]

If you wanna eat it just eat it. You don't have to be a little freak about it.

The channel is Programmer Humor, not Programming Humor

The comments are symptomatic of the instance itself being unmoderated. The instance admin is MIA and right-wingers are using that absence to create a cesspit.

The AUR is the reason I don't use Arch. It's a huge pain in the ass and the opposite of lazy. I truly don't understand this comment.

Maybe I'm misunderstanding the point of the AUR, but my understanding of it is that it fills a similar role as PPAs/third party repos in debian/ubuntu. To use the AUR, you have to first:

1. Install base-devel.
2. Install an AUR helper (unless you want to do all this fully manually). But the AUR helpers are themselves on the the AUR so you have to learn to use it and go through all these steps yourself at least once.

Then, for every package you have to:

1. Download the package build file. (The AUR helper can do this for you)
2. Review the package build file. AUR helper tools don't let you skip this step, despite it being mostly security theater.
3. Install the build dependencies. (The AUR helper can do this for you)
4. Compile the software on your own machine. (There are some binary packages on the AUR, but it seems most are source packages). This takes time and replicates work, wasting electricity. This step must be done as a normal user. None of the tools I found will de-escalate privileges if you are already superuser for the build step.
5. Install the resulting package using pacman, as a superuser. Note that if you have an AUR helper, you have install sudo and run as a user that has sudo privileges.

Then, every time you want to upgrade the software, you have to do it all again.

Admittedly, this is not a ton of work. But having to do it for every package and every upgrade is a very real hassle, when most of the time I just want to be using my computer.

Contrast this to a PPA/third party repo in debian/ubuntu.

1. Search for the repository.
2. Copy/paste the commands to enable it.
3. apt update && apt install package

... and you're done. You get seamless automatic upgrades. There's no compilation or need to install extra build dependencies. It's so much easier.

I truly do not get why Arch users put up with the AUR.

Hell yeah

Ran across one of their posts on the local feed here and I have to agree, we should defederate.

You could try a VM with just Firefox to see if there's another program interfering with it?

Passkeys (which are broader than just Apple) and this are not related at all. Regardless, Apple absolutely has interest in controlling browsers. Hell, they already do it on iOS, where you can't use any rendering engine other than theirs.

The only reason they might be against this is because they feel they can't control it the way they want.

The title should be "Influencer dies after contracting cholera-like disease and refusing medical help."

It's a great game! It's available on all the platforms & worth every penny.

My opinion: don't sweat it, either way. I know that's easy to say from the outside, but it's still true. Do what you are most comfortable with. It sounds like you have plenty of ammunition if you want to put your foot down & insist on quality practices. Reject PRs that don't meet best practices, and point to the internal docs you have. If the dev reacts angrily, blame the company & say you are worried about getting in trouble.

Or if confrontation makes you more uncomfortable, just let it slide. If the shit hits the fan, the senior dev is the senior dev. Just say you were following their lead.

Above all, remember that the company you are working for is not your friend and not your ally. Look out for your own interests first & don't stress about work as much as possible (I get that's easy to say and tough to do, but it's still the best idea!)

This sounds like the argument of someone who doesn't want to be faced with the facts.

literally re-inflating the bouncy castle

What if my computer isn't attached to a bouncy castle? Do I need to buy special hardware for this?

Thanks for reminding me to delete my account & all its posts

Just use Signal or Matrix.

The Microsoft ❤️ Linux image is a weird choice. WSL is neat but Microsoft will never support Linux on their hardware.

Umm excuse me you stopping your conversation is overstepping my boundaries for this situation

Oh hey, don't worry, the earth will be fine. We'll all die, but the earth? It'll still be here