Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

attempt to access private resource denied #21

Closed
jacknlliu opened this issue Sep 3, 2015 · 13 comments
Closed

attempt to access private resource denied #21

jacknlliu opened this issue Sep 3, 2015 · 13 comments

Comments

@jacknlliu
Copy link

@jacknlliu jacknlliu commented Sep 3, 2015

After I run the docker container of osrf/ros, I got the following error, and the GUI not work!
$ docker run -it --security-opt="label:disable" --env="DISPLAY" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" osrf/ros:indigo-desktop-full rqt

X Error: BadAccess (attempt to access private resource denied) 10
Extension: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0x135
X Error: BadShmSeg (invalid shared segment parameter) 128
Extension: 130 (MIT-SHM)
Minor opcode: 3 (X_ShmPutImage)
Resource id: 0x2000008

I tried it on Fedora22 X86_64.

@j-rivero
Copy link
Contributor

@j-rivero j-rivero commented Sep 3, 2015

The MIT-SHM is an extension to the X server which allows faster transactions by using shared memory. Docker isolation probably blocks it. Qt applications can be forced not to use the extension. Try using:

--env QT_X11_NO_MITSHM=1

It could be a good idea to add it to the images (for rviz and rqt).

@ruffsl
Copy link
Member

@ruffsl ruffsl commented Sep 3, 2015

As @j-rivero points out a relevant issue with Qt, forgetting this flag results in much of the GUI windows button or menu interfaces not being rendered. How ever if you are having a Bad Access error, my guess is that your having and a permission or authentication problem using the mounted Unix socket from within the container. You should peruse through some notes on the topic I wrote in the ROS Docker wiki here:
http://wiki.ros.org/docker/Tutorials/GUI
If you see anything that needs concretion in the wiki, just let me know.

Also, for some image sensors in gazebo, we might need GPU access within the container.
See this nvidia folder to get a feel on how to add a layer with the necessary drivers and mount the devices:
https://github.com/CognitiveRobotics/omnimapper/tree/master/docker/nvidia
I'll have to write this in detail in the ROS Docker wiki when I have time this week.

@tfoote
Copy link
Contributor

@tfoote tfoote commented Sep 3, 2015

I can reproduce the problem and using the env from @j-rivero it is fixed. Also this is in the troubleshoot section of the GUI tutorial. I added the error message for easier searching in the future.

@jacknlliu
Copy link
Author

@jacknlliu jacknlliu commented Sep 4, 2015

This option
--env QT_X11_NO_MITSHM=1
fixed that problem.
Thanks!

@ruffsl ruffsl closed this Oct 27, 2015
@graywolf
Copy link

@graywolf graywolf commented Aug 11, 2016

alternative solution is to pass --ipc host and take advantage of MIT-SHM performance

@ruffsl
Copy link
Member

@ruffsl ruffsl commented Aug 12, 2016

@graywolf , I'm not familiar with IPC namespace, or MIT-SHM. Could you elaborate?

@graywolf
Copy link

@graywolf graywolf commented Aug 12, 2016

@ruffsl as @j-rivero wrote

The MIT-SHM is an extension to the X server which allows faster transactions by using shared memory.

docker's --ipc setting: https://docs.docker.com/engine/reference/run/#/ipc-settings-ipc allows accessing shared memory between x11 and application running in container. But I'm no expert on it either.

It could open security holes though ( I made SO question, hopefully will someone answer http://stackoverflow.com/questions/38907708/docker-ipc-host-and-security ), I don't know enough to say for sure. But if you trust application inside (which is this case I suspect) and use docker more for convinience than security, you could just allow it.

PS: GPU benchmark (with --ipc host) showed identical performance in container and on host system (well technically the container was .5 FPS faster :) ).

@ruffsl
Copy link
Member

@ruffsl ruffsl commented Aug 12, 2016

@graywolf , If you wouldn't mind, could you document your findings on the wiki: http://wiki.ros.org/docker/Tutorials/GUI , that would be awsome. What additional arguments do you need, just the volume for the x11 unix socket, or not even that?

@graywolf
Copy link

@graywolf graywolf commented Aug 12, 2016

Preface

Tbh I would mind, I don't even have any idea what this project is, I just found this issue when googling for

X Error: BadAccess (attempt to access private resource denied) 10
Extension: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0x135

so I don't feel like qualified person to edit your wiki :) Since this page is relatively high in google search, I thought I would leave here what I found for future people having this problem. I don't even know if GUI performance is important enough for you (I was benchmarking OpenGL so for me it was). But I can make a summary of what I managed to figure out and if you find it useful you (or someone) can incorporate it into your wiki :)

Image creation

I'm using Archlinux as a base, so steps will probably need to be adapted to your base. This Dockerfile could probably be optimized (quite) a bit, I was focused on getting in to work, not on keeping in smallest possible size. Folder uh40 contains Unigine Benchmark 4.0, Heaven.

FROM base/archlinux

RUN pacman-key --refresh-keys
RUN pacman-key --recv-keys arch@eworm.de arojas@us.es
RUN pacman -Syyu --noconfirm
RUN pacman-db-upgrade
RUN pacman -S ca-certificates-mozilla --noconfirm
RUN pacman -S mesa-demos xf86-video-ati mesa-libgl --noconfirm
COPY uh40 /uh40
RUN pacman -S fontconfig --noconfirm
RUN useradd -m -d /home/gui -s /bin/bash gui
RUN usermod -a -G video gui
RUN pacman -S xorg-server xorg-server-utils xorg-apps --noconfirm
USER gui
ENV vblank_mode=0
WORKDIR /uh40
CMD ["./heaven"]

Seems more complicated than it is. Basically it just updated archlinux base to newest version and install gui drivers & libraries.

Note: You need to pick driver depending on your GPU (or install them all), I have ATI card, so for me it's xf86-video-ati.

Note2: this is probably not smallest possible, from xorg-server, xorg-server-utils and xorg-apps could be picked only needed packages instead of whole groups. xorg-apps is possibly not needed at all.

Running

xhost +local:docker
docker run -it \
    -e DISPLAY="$DISPLAY" \
    -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
    --device /dev/snd:/dev/snd \
    --device /dev/dri:/dev/dri \
    --ipc host \
    heaven-archlinux

Note: The line with /dev/snd is not needed if you don't care about sound.

End

If you think this could be useful you this project, go ahead and incorporate it into the wiki :) I have no doubt it could be simplified quite a bit since you already have working image etc.

Hope this will be helpful to someone ^_^

@ruffsl
Copy link
Member

@ruffsl ruffsl commented Aug 12, 2016

@graywolf , pardon my assumption, I guess these pages on Docker and GUIs are more general traffic than just fellow ROS users. I'll try this out for out ubuntu bases and incorporate it into the wiki. Does this no longer require adjusting the allowed xorg users on the host, i.e. doing xhost +local:root?

(P.S. awesome GITS related avatar by the way.)

@graywolf
Copy link

@graywolf graywolf commented Aug 12, 2016

Ups, I forgot that part (it's not in the bash script I used to launch it :D ). You are right of course, that part is still needed. I went with xhost +local:docker though.

And thanks :)

osrf-docker-builder pushed a commit to osrf-docker-builder/docker_images that referenced this issue Oct 6, 2017
Oblynx added a commit to Oblynx/HierarchicalTemporalMemory.jl that referenced this issue May 4, 2018
GR plots couldn't display with the ubuntu images, probably due to
missing packages. To support them, followed the instructions in
http://gr-framework.org/tutorials/docker.html

- Image based on fedora
- Julia built from source, takes a long time
- docker --ipc=host opens a potential security hole. Based on
    osrf/docker_images#21
dilawar pushed a commit to BhallaLab/deploy that referenced this issue Oct 30, 2018
@AnkS4
Copy link

@AnkS4 AnkS4 commented Jul 5, 2019

I am able to launch gazebo using @graywolf 's way, but the model inside is not launching up.
There's no Errors in the dokcer log.

2019-07-05-203058_1366x768_scrot
2019-07-05-203517_1366x768_scrot

@ruffsl
Copy link
Member

@ruffsl ruffsl commented Jul 6, 2019

@AnkS4 , if you're able to view the GUI window, but not the 3D rendered view, I think that would be an issue with enabling the hardware acceleration for 3D graphics. I'd say check your approach with the wiki, or use a tool to setup your environment for you:

http://wiki.ros.org/docker/Tutorials/GUI
or
https://github.com/osrf/rocker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.