Bug 754242
Summary: | "shutdown -r 0" "reboot" kills my RAID "can't access tty" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | brian.broussard |
Component: | mdadm | Assignee: | Doug Ledford <dledford> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | agk, dledford, Jes.Sorensen, mbroz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-11-17 19:04:33 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: |
Description
brian.broussard
2011-11-15 20:25:31 UTC
Yes we do indeed test on real hardware, however adding a user to sudo in order for the user to be able to call shutdown -r 0 isn't the most common nor recommended usage case. Does this problem still occur under Fedora 16? On a side note, you really would want x86_64 on there to avoid the system using bounce buffers constantly when running the i686 kernel. Jes Hello I ask about hardware because we can not reproduce the issue using VBox or VMware, only on the targets. what would your commendation be for a non-administrative user to reboot / shutdown a system that does not operate a windows manager? Sudoers file has a commented line that allows all users to issue a reboot / shutdown this is not acceptable for as as it is not in compliance with our security plan toallow everybody to shutdown/reboot. But if you uncomment that line and allow users same issue. from /etc/sudoers # %users localhost=/sbin/shutdown -h now Testing in F16 has Not reproduce the issue, but there is an issue with the box stopping the process and a hard power off required. not sure if that helps or hurts. Bug https://bugzilla.redhat.com/show_bug.cgi?id=752593 Can not move the x86_64 third party components will not move and have not replaced them all as of yet. Stuck with i386 tree only.... We are pushing to try to get there. Note sure what to do today we have been shipping i7 machines which required me to move away from FC11 (were going to update all filed systems to FC15 but have stopped) and did not see this issue until we YUM a production box to fix a different issue and started seeing this RAID problem..... we are doing some funny things right now in our build process to get the set of packages we need to run but if a field machine is YUMed they will pretty much lose some data. Not good I understand. So your recommendations would to move to x86_64 and not let users reboot only root or process running with hight enough privileges. If you really wish for all users to be able to reboot the system you could simply suid the /sbin/shutdown binary - still I would not recommend this, just as I wouldn't recommend what you are doing. How is your system configured? Are the user's home directories located on the RAID device? is / on the RAID? Jes Yes "/" down is on the raid. So what is the method for rebooting a box as a non root user? Yes adding s bit to the shutdown it what most people state, but that allows all ... just trying to follow good layered security for hipaa. Which requires a user to admin certain parts of the box without access to others. I am calling all my vendors today and see about fc16 with x86_64 Thanks well if it works for root to do the shutdown, it might work for you to let the user execute 'su -c /sbin/reboot' through sudo. My guess is that something goes wrong because it is unable to unmount the raid because something through the chain of the sudo call keeps some user file descriptor open on the raid. The problem with IMSM RAID is that the metadata is managed through mdmon, so as long as the RAID is read-write, you cannot shutdown mdmon, and allow for a clean reboot. Hello thanks we will be moving to Fedora 16 and dealing with upstream issues the RAID support seams better can not reproduce the issue in Fedora 16 thanks again. |