[gentoo-user] Re: FreeCAD permission problems

[Kai Krakow]

Am Sat, 6 May 2017 14:42:59 +0200
schrieb tuxic@××××××.de:

> On 05/06 02:16, Kai Krakow wrote:
> > Am Sat, 6 May 2017 12:55:24 +0200
> > schrieb tuxic@××××××.de:
> >
> > > On 05/06 12:28, Kai Krakow wrote:
>  [...]
>  [...]
> > >  [...]
> > >  [...]
>  [...]
> > >  [...]
>  [...]
> > >  [...]
>  [...]
> > >  [...]
>  [...]
> > >  [...]
> > >  [...]
>  [...]
>  [...]
>  [...]
>  [...]
> > >
> > > Hi,
> > >
> > > ...it runs now at least for root (called as user it crashes
> > > still).
> > >
> > > I did the following:
> > >
> > >
> > > mv /usr/lib64/libGL.so  /usr/lib64/off.libGL.so
> > >
> > > for all libGL.so* in /usr/lib64/libGL.so*
> >
> > You shouldn't shuffle those files around. They are controlled by the
> > package manager.
> >
> > I think it's a bug of the software that it overwrites ld paths.
> > With a Gentoo standard configuration and eselect opengl switched to
> > nvidia, every software should find and load the nvidia opengl stuff
> > first.
> >
> > Could you show the output of
> >
> > # lddtree $(which FreeCAD)
> >
> > E.g., lddtree $(which kwin_x11) shows a line for me:
> >
> > libGL.so.1 => /usr/lib64/opengl/nvidia/lib/libGL.so.1
> >
> > which clearly says it's linking libGL.so.1 from nvidia first.
> >
> > If a libGL line is missing for FreeCAD, it is dynamically loaded by
> > the application itself. Then it's a FreeCAD bug that should be
> > fixed.
> >
> > If it's loading from /usr/lib64/libGL* for you, then some paths and
> > configs are borked in your system.
> >
> >
> > > Addtionally I added 06nvidia to /etc/ld.so.config.d/. with this
> > > contents:
> > > /usr/lib64/opengl/nvidia/lib
> > > and did a ldconfig afterwards and reboot to release any
> > > filehandle.
> >
> > I wonder why these paths are missing for you... My ld.so.conf has
> > nvidia paths right in the beginning (first two lines). It's
> > actually made from /etc/env.d/000opengl. There's nothing nvidia
> > specific in the .d directory.
> >
> >
> > > One question remains:
> > > It works for root but not for any other user.
> > > I (as user) am in the video group.
> > >
> > > I checked the directory/file permissions of opencascade and they
> > > seem to be ok.
> >
> > I don't think that modern kernels and desktop managers still use the
> > video group. It should be handled by ACLs. Please have a look at the
> > ACLs of the device nodes.
> >
> > It all depends on your login manager and pam configuration. You
> > should check that if things don't work right. If you're using
> > systemd, you are using systemd-logind, otherwise you're probably
> > using consolekit.
> >
> > If you're not using either of those, the system would fall back to
> > standard unix group permissions. But I'm not sure if this works
> > correctly if you didn't configure the whole chain to work that way.
> >
> >
> > > I straced FreeCAD...but...I fear not to see anything suspicious
> > > because the output contains a lot of noise (much more as normally
> > > seen in such traces)...
> >
> > You can use call filters to limit that to what you want to see.
> > Also, there's ltrace which could be interesting.
> >
> >
> > > The eselects show:
>  [...]
> > > Available OpenGL implementations:
> > >   [1]   nvidia *
> > >   [2]   xorg-x11
>  [...]
> > > i915 (Intel 915, 945)
> > > i965 (Intel GMA 965, G/Q3x, G/Q4x, HD)
> > > r300 (Radeon R300-R500)
> > > r600 (Radeon R600-R700, Evergreen, Northern Islands)
> > > sw (Software renderer)
> > >   [1]   classic
> > >   [2]   gallium *
> > >
> > > Why is nvidia not listed with the second command?
> >
> > Afaik, it does not provide mesa drivers. That's probably why it
> > cannot find an "swrast" driver/visual then. Directly using nvidia
> > OpenGL fixes that, which is what you did now.
> >
> > I think the bug with FreeCAD is, that it cannot properly handle
> > multiple opengl implementations which it tries to do itself. It
> > should be left to the system to correctly load the correct opengl
> > implementation.
> >
> > I guess FreeCAD looks up visuals by loading libGL from /usr/lib,
> > then it loads libGL again using means provided by the system, which
> > ends up loading the nvidia implementation. But that does not
> > provide swrast. I can only guess why they did that. But I could
> > also be totally wrong.
> >
> >
> > --
> > Regards,
> > Kai
> >
> > Replies to list-only preferred.
> >
>
>
>
>
> Hi Kai,
>
> NO PANIC! :) the renaming of libGL and friends was for
> testing/experimenting purposes only! :)
>
> After renaming those back to normal and doing a ldconfig
> these were back for root and user:
>
>     libGL error: No matching fbConfigs or visuals found
>     libGL error: failed to load driver: swrast
>     *** Abort *** an exception was raised, but no catch was found.
>         ... The exception is:SIGSEGV 'segmentation violation'
> detected. Address 0
>
> I checked for the 000opengl file in /etc/env.d on my installation and
> it is there...so I removed my file under /etc/ld.config.d/.
>
> lddtree /usr/bin/FreeCAD gives me:
>
> FreeCAD => /usr/bin/FreeCAD (interpreter => /lib64/ld-linux-x86-64.so.2)
[...snip...]
> libGL.so.1 => /usr/lib64/libGL.so.1
[...snap...]

So it's loading the wrong lib...

Let's find out why... Is there /etc/env/000opengl?

Did you run env-update and logged out and in again? (or rebooted)

If all yes, you should in /etc/ld.so.conf that the very first lines
(after the comments) are for the nvidia opengl implementation.

> Next: ACL
>
> What? ;)

Access control lists...

It's fine grained controls than posix access controls
(user,group,others,owner,group-owner etc).

If you "ls -l" the dev directory, you should notice a "+" behind some
permissions. This actually tells you that there are ACLs. The input
devices you're using should show that:

$ ls -al /dev/input/event*
crw-rw----+ 1 root input 13, 69  6. Mai 13:28 /dev/input/event5

$ getfacl /dev/input/event5
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event5
# owner: root
# group: input
user::rw-
user:kakra:rw-
group::rw-
mask::rw-
other::---

So you see, additionally to root:input=rwrw it also gave my user
explicit rw permissions. This is handled by the login manager which
gives users exact permissions to only the devices attached to that seat
instead of generic access for everything, no matter how the user logged
in. E.g., why would you need access to those devices if logged in by
SSH? Even if you have local login permissions, why should those be
valid when logged in by remote?

This problem is fixed by ACLs.

Other essential devices should show similar ACLs for you.

BTW: I'm in the video group, too. I think this is required for nvidia
drivers. So I don't believe that is the problem for you and we are on
the wrong path here. You should check that /dev/nvidia* belongs to the
video group, tho. Otherwise check that NVreg_DeviceFileGID matches your
video group id in /etc/modprobe.d/nvidia.conf.

Does glxgears work for you?


> Sorry Kai...you hit the blank spot of my knowledge of Linux here.
> Please give me some hints...

I hope I did.


> To summarize:
> I am using good 'ole openrc. Consolekit is installed.
> My login manager is slim.

It's systemd and sddm here...

I ditched consolekit long time ago so I cannot really help you here by
comparing with my local configuration.


> ltrace:
> I will take a look, what I may find with that one.
> strace: It is difficult to filter unimportant things
> as long I dont know the reason (the important thing)
> for the problem... ;) :)
> But I will take a deeper look...

You could enable coredumps and feed that to gdb to get a backtrace. But
I believe you need to enable debug symbols in portage and
recompile stuff to have debug info. Even if incomplete, it could be
helpful to identify the offender. Maybe it can be fixed by preloading
older .so files.


-- 
Regards,
Kai

Replies to list-only preferred.