Hello!
I confirm that this is fixed with nvidia-modprobe 384.111-2.
Thanks a lot!
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
I comfirm that setuid(0) fixes my issue! Thank you for your advise.
I made a small patch of the workaround for nvidia-modprobe.
Please check the attached file.
The configuration in /etc/modprobe.d/nvidia.conf requires
to fork /bin/sh with root privilege because it contains some shell commands.
So
Hiromasa YOSHIMOTO writes:
> I wrote small program to reproduce this issue.
> Could you check and try the attached code?
> The step is:
> $ gcc check.c -lcap -omain
> $ cp main sub # "sub" corresponds to insmod that
> causes EPERM
> $ sudo chown 0.0 main
> $ sudo chmod u+s m
Dear andreas,
I figured out why CAP_SYS_MODULE is removed in my environment.
My /sbin/modprobe uses system(3) to create a sub process internally(*1),
and drops the capability.
According to man page (*2), I think this is expected behavior.
*1 kmod-25/libkmod/libkmod-module.c:996
*2 http://man7.or
Dear andreas,
Thank you for your information. I've just checked CAP_SYS_MODULE capability.
First, EPERM is returned by finit_module syscall. It is defined
in linux-4.14/kernel/module.c and checks CAP_SYS_MODULE as below;
static int may_init_module(void)
{
if (!capable(CAP_SYS_MODULE) ||
On 2018-02-05 18:12, Andreas Beckmann wrote:
>EPERM The caller was not privileged (did not have the CAP_SYS_MODULE
> capability), or module loading is disabled (see
> /proc/sys/kernel/modules_disabled in proc(5)).
> So perhaps we need to apply some capabilities to nvidia-modprobe, try t
Andreas,
> Are there any hardening settings enabled on your system that could
> prevent this setuid executable from doing its job?
> * filesystems mounted with option nosuid
> * apparmor
> * selinux
> ...
Yes apparmor is installed.
> BTW, which version of the nvidia-modprobe package do you have
I still cannot reproduce it ...
On 2018-02-05 16:11, Hiromasa YOSHIMOTO wrote:
> modprobe: INFO: ../libkmod/libkmod.c:364 kmod_set_log_fn() custom logging
> function 0x559425f77b90 registered
> modprobe: INFO: ../libkmod/libkmod-module.c:886 kmod_module_insert_module()
> Failed to insert module
Dear Andreas,
I checked modprobe behaviors by using its "-vv" option as you suggested.
I ran the following commands:
$ sudo /sbin/rmmod nvidia-uvm
$ /usr/bin/nvidia-modprobe -u > without_sudo.log 2>&1
$ sudo /usr/bin/nvidia-modprobe -u > with_sudo.log 2>&1
Please check the attached files for
On 2018-02-05 10:37, Hiromasa YOSHIMOTO wrote:
> Dear Andreas,
>
> Thank you for your small program.
> I have no problem with setuid binaries on my system.
>
> I’ve checked also the source code of nvidia-modprobe,
> and modified it to show the error messages. The diff is as follows.
Thanks for c
Dear Andreas,
Thank you for your small program.
I have no problem with setuid binaries on my system.
I’ve checked also the source code of nvidia-modprobe,
and modified it to show the error messages. The diff is as follows.
--- nvidia-modprobe-384.111.orig/modprobe-utils/nvidia-modprobe-utils.c
+
I've prepared a small program to help debugging whether setuid binaries
work on your system:
= test-setuid.c =
#include
#include
#include
int main()
{
printf("getuid() = %ld\n", (long)getuid());
printf("geteuid() = %ld\n", (long)geteuid());
printf("getgid() =
How can I unsubscribe from this list? For years now, I have been asking how to
unsubscribe and nothing has worked.
> On 5 Feb 2018, at 07:54, Andreas Beckmann wrote:
>
> On 2018-02-05 08:44, Hiromasa YOSHIMOTO wrote:
>> Although nvidia-modprobe is setuided, it seems
>> not to work properly as e
On 2018-02-05 08:44, Hiromasa YOSHIMOTO wrote:
> Although nvidia-modprobe is setuided, it seems
> not to work properly as expected.
Which is probably caused by some hardening configuration on your
systems. Is there anything about nvidia-modprobe in the logfiles in
/var/log/ ?
Andreas
Hi Hiromasa,
I found a reproduce step. Could you try this?
>
I can reproduce with those steps indeed.
Thanks a lot!
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://photos.obry.net
http://www.obry.net
gpg --keyserver keys.gnupg.net
On 2018-02-05 08:02, Pascal Obry wrote:
> First, unload is not possible as nvidia is in use.
in that case you could either stop X and work in the console ...
or just do the following steps, since obviously only the nvidia-uvm
module in interesting here, there is no need for rebooting:
$ sudo modp
Dear maintainers,
I found a reproduce step. Could you try this?
$ sudo modprobe -r nvidia_uvm
$ clinfo
$ nvidia-modprobe -u
$ clinfo
$ sudo modprobe nvidia_uvm
$ clinfo
I’m using newer driver 390.25-1 from SVN.
Although nvidia-modprobe is setuided, it seems
not to work properly as expected.
Hello Andreas,
Thanks for your feedback. I have just rebooted and tested as you
proposed:
First, unload is not possible as nvidia is in use.
$ sudo modprobe -r nvidia
[sudo] password for obry:
modprobe: FATAL: Module nvidia_drm is in use.
modprobe: FATAL: Error running remove command for nvidia
Control: tag -1 moreinfo
On 2018-01-31 15:45, Pascal Obry wrote:
> I don't understand why clinfo as root seems to "unblock" something. Any idea?
it loads the kernel module, which *should* also work if clinfo is run as
regular user
> I have reproduced this 2 times, so I'm pretty sure about the ab
Package: nvidia-driver
Version: 384.111-4
Since 384.111-3 (for sure, maybe even with older version) OpenCL is not
activated at boot. That is, after I log:
$ clinfo
Number of platforms 0
What I found (by chance) is that running clinfo as root works:
$ sudo clinfo
Nu
20 matches
Mail list logo
