Bug 188091
Summary: | hal does not adhere to fdi policy for mount options | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christopher Aillon <caillon> |
Component: | hal | Assignee: | David Zeuthen <davidz> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | davidz, mclasen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-28 23:31:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 188092 |
Description
Christopher Aillon
2006-04-05 22:34:22 UTC
Right, I did suggest to file this as a security bug just in case. However, the effect is that noexec always gets applied and that was intended back then when I wrote the /usr/share/hal/scripts/hal-system-storage-mount script - in fact just to be on the safe side we always append noexec,nosuid,nodev. (btw, in upstream hal this rather fragile (yet secure I'd argue) script is replaced by C code using glib and I feel a lot more confident that way) I agree with you insofar that the right answer here is to allow both 'exec' and 'noexec' and make e.g. gnome-mount uses 'noexec' as default and 'exec' for fixing the autorun case (which you filed as bug 188092)... This is relaxing things a little bit but, really, noexec never really made things secure as users could always move files to /tmp or $HOME and chmod a+x said file. Surely we still want to apply nodev and nosuid. So there is no security issue here. I'm adjusting this bug to remove the security senstive flags etc. I have made a note to fix this upstream. Patches against HAL CVS HEAD welcome. This can be closed now I think. (see explanation in bug 188092 for details) |