Bug 893037

Summary: "depmod -a" and wrong permissions
Product: [Fedora] Fedora Reporter: Harald Reindl <h.reindl>
Component: kmodAssignee: kmod development team <kmod-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: jonathan, kmod-maint, msivak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-17 14:01:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Harald Reindl 2013-01-08 13:54:30 UTC 
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
Comment 1 Josh Boyer 2013-01-08 14:25:08 UTC 
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.
Comment 2 Harald Reindl 2013-01-08 14:30:53 UTC 
[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
Comment 3 Josh Boyer 2013-01-08 14:49:56 UTC 
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.
Comment 4 Josh Boyer 2013-01-17 14:01:11 UTC 
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.