Want /dev/zfs umask module parameter #4119
Conversation
We introduce a module parameter that enforces a umask on /dev/zfs. It was originally meant to be set only at module load time, but some difficulties with `modprobe zfs zfsdev_umask=777` in local testing lead me to allow its owner (default root) to change it at runtime. This should ease the transition for those that rely on this behavior, provided that we state in the release notes that future releases are expected to remove the ability to modify it at runtime. When the cause of that modprobe command failing to set the module is found, we can tighten the permissions for a future release. Closes openzfs#4100 Signed-off-by: Richard Yao <[email protected]>
| @@ -195,6 +195,9 @@ | |||
| kmutex_t zfsdev_state_lock; | |||
| zfsdev_state_t *zfsdev_state_list; | |||
|
|
|||
| /* The bits are stored in decimal format, not octal */ | |||
| int zfsdev_umask = 77; | |||
There was a problem hiding this comment.
I felt using a decimal format would be easier for those reading the setting in /sys/module/zfs/parameters/zfsdev_umask, but I am open to switching to octal if people prefer that.
|
I don't see any point of doing this. |
|
@tuxoko raises a good point, and even if we add a patch like this it won't end up in a tagged release for quite some time. This is perhaps a good example of a patch which should just be carried in to the gentoo patch stack until such time as they fix this issue in their distribution. |
|
Closing. @ryao your welcome to apply an updated version of this to Gentoo, but for the moment there doesn't appear to be a need for this elsewhere. |
We introduce a module parameter that enforces a umask on /dev/zfs. It
was originally meant to be set only at module load time, but some
difficulties with
modprobe zfs zfsdev_umask=777in local testing leadme to allow its owner (default root) to change it at runtime. This
should ease the transition for those that rely on this behavior,
provided that we state in the release notes that future releases are
expected to remove the ability to modify it at runtime. When the cause
of that modprobe command failing to set the module is found, we can
tighten the permissions for a future release.
Closes #4100
Signed-off-by: Richard Yao [email protected]