forget the fc18, i have run the 3.7.1 on F17 maybe depending on the current umask "depmod -a" is changing the permissions of SOME files under /lib/modules to chmod 640 this leads in that VMware running as normal user believes that the modules are missing and is a wrong behavior which is fixed with a workaround of VMware if the modules are built due boot process this workarounds should not be needed and modules.* become 644 as default [root@rh:/lib/modules/3.7.1-2.fc18.x86_64]$ ls insgesamt 2,5M drwxr-xr-x 12 root root 4,0K 2013-01-07 10:02 kernel drwxr-xr-x 2 root root 4,0K 2013-01-07 10:08 misc drwxr-xr-x 2 root root 4,0K 2013-01-04 01:17 updates drwxr-xr-x 2 root root 4,0K 2013-01-07 10:02 vdso lrwxrwxrwx 1 root root 36 2013-01-07 10:02 build -> /usr/src/kernels/3.7.1-2.fc18.x86_64 lrwxrwxrwx 1 root root 5 2013-01-07 10:02 source -> build -rw-r--r-- 1 root root 635K 2013-01-07 10:08 modules.alias -rw-r--r-- 1 root root 629K 2013-01-07 10:08 modules.alias.bin -rw-r--r-- 1 root root 9,0K 2013-01-07 10:08 modules.builtin.bin -rw-r--r-- 1 root root 311K 2013-01-07 10:08 modules.dep.bin -rw-r--r-- 1 root root 292K 2013-01-07 10:08 modules.symbols.bin -rw-r--r-- 1 root root 1,7K 2013-01-04 01:17 modules.block -rw-r--r-- 1 root root 6,7K 2013-01-04 01:14 modules.builtin -rw-r--r-- 1 root root 215K 2013-01-07 10:08 modules.dep -rw-r--r-- 1 root root 274 2013-01-07 10:08 modules.devname -rw-r--r-- 1 root root 95 2013-01-04 01:17 modules.drm -rw-r--r-- 1 root root 88 2013-01-04 01:17 modules.modesetting -rw-r--r-- 1 root root 2,1K 2013-01-04 01:17 modules.networking -rw-r--r-- 1 root root 89K 2013-01-04 01:14 modules.order -rw-r--r-- 1 root root 131 2013-01-07 10:08 modules.softdep -rw-r--r-- 1 root root 232K 2013-01-07 10:08 modules.symbols [root@rh:/lib/modules/3.7.1-2.fc18.x86_64]$ depmod -a [root@rh:/lib/modules/3.7.1-2.fc18.x86_64]$ ls insgesamt 2,5M drwxr-xr-x 12 root root 4,0K 2013-01-07 10:02 kernel drwxr-xr-x 2 root root 4,0K 2013-01-07 10:08 misc drwxr-xr-x 2 root root 4,0K 2013-01-04 01:17 updates drwxr-xr-x 2 root root 4,0K 2013-01-07 10:02 vdso lrwxrwxrwx 1 root root 36 2013-01-07 10:02 build -> /usr/src/kernels/3.7.1-2.fc18.x86_64 lrwxrwxrwx 1 root root 5 2013-01-07 10:02 source -> build -rw-r----- 1 root root 635K 2013-01-08 14:50 modules.alias -rw-r----- 1 root root 629K 2013-01-08 14:50 modules.alias.bin -rw-r----- 1 root root 9,0K 2013-01-08 14:50 modules.builtin.bin -rw-r----- 1 root root 311K 2013-01-08 14:50 modules.dep.bin -rw-r----- 1 root root 292K 2013-01-08 14:50 modules.symbols.bin -rw-r--r-- 1 root root 1,7K 2013-01-04 01:17 modules.block -rw-r--r-- 1 root root 6,7K 2013-01-04 01:14 modules.builtin -rw-r----- 1 root root 215K 2013-01-08 14:50 modules.dep -rw-r----- 1 root root 274 2013-01-08 14:50 modules.devname -rw-r--r-- 1 root root 95 2013-01-04 01:17 modules.drm -rw-r--r-- 1 root root 88 2013-01-04 01:17 modules.modesetting -rw-r--r-- 1 root root 2,1K 2013-01-04 01:17 modules.networking -rw-r--r-- 1 root root 89K 2013-01-04 01:14 modules.order -rw-r----- 1 root root 131 2013-01-08 14:50 modules.softdep -rw-r----- 1 root root 232K 2013-01-08 14:50 modules.symbols
What is the umask for root on that box? Your theory about it depending on umask might make sense, but I'd like to see if it is indeed plausible, so knowing what the umask is would be helpful.
[root@rh:~]$ umask 0027 that is because on the machine are running several services like httpd and so on for development and i do not like new files witout explicit permissions readable by all of them, that is why i think depmod should be explicit about the permissions
Well, depmod already is explicit about the permissions on the files. The code that creates them calls openat with O_CREAT | O_TRUNC | O_WRONLY and mode = 0644. However, openat honors umask has it has forever. This isn't really a bug per se. It is behaving like every other process would with a umask like that. I'll email upstream about whether or not depmod should call umask(2) to set its own explicit umask. I'm somewhat doubtful that will be viable.
Upstream also did not think this was a bug. depmod is honoring umask as it should. If you would like to run depmod and still allow users to read the files, then set a umask that allows that before running depmod.