From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 StumbleUpon/1.998 Description of problem: System-config-users should not allow you to delete "user's home directory" if that directory is not located under "/home/". I realize that some systems might have home directories in a different location, for example "/exports/home". If this is an issue, perhaps system-config-users could have an option to specify the location of user home directories and not delete directories outside of that location. Many of the default system accounts have their home directory set to "/". If you delete one of them, or create an account modeled after one of them and then delete it, system-config-users asks you if you want to delete the home directory. If you click yes, it happily goes off to delete your "/" directory. (Can you guess why I'm filling this). This is somewhat a "user-error" but it's also a case of the software doing something that: a) You hardly even want to do legitimatly b) You can do manually if you really need it. c) There is an enormous amount of reseach showing that it is unreasonable to expect confirmation dialog boxes to jog user's out of something that normally wouldn't be a problem. Version-Release number of selected component (if applicable): system-config-users-1.2.26-0.fc2.1 How reproducible: Always Steps to Reproduce: 1. Create an account. 2. Set the "Home Directory" fiels to "/" (as it is for an account like "nobody") 3. Delete the account Actual Results: system-config-users offers to delete the user's home directory (without even displaying what will be deleted) Expected Results: Expected System-config-users either: a) Deletes the account without offering to remove the home directory or b) Deletes the account and explains that the home directory will not be deleted because it is not under /home (or if there is an option to set the home location, that location). Additional info:
Created attachment 106170 [details] Don't offer to delete the home directory if it is set to "/" I know this isn't exactly what I described in the bug report, but it's the best I can do, not knowing Python.
The Right Solution might be to only delete the directory if it is not owned by an rpm package. Filtering based on pathname patterns is going to be error-prone.
By the way, as I infered in the report, I ran into this feature as I was trying to add a user to run the Perforce server as. I created the account and, thinking I should just model the other system accounts, set the home directory to "/". Sometime later, I decided to use a different name for the server's account and went to delete it (not remembering or noticing what the home directory was set to). So, it managed to delete all of /boot and /dev. It was trying to delete /proc when I noticed a bunch of errors (thank god I started it from the command line). Anyway, the point of this response is to actually say *thanks* to everyone who actually works on this stuff. It was almost a disaster, but I just had to rpm -ivh --force the dev package, the kernel package, MAKEDEV, redhat-logos, copy over a working grub.conf, and run grun-install. Having packages that just re-install the right thing made it soooo much simpler. So, thanks for a system that it is possible to recover from disasters without having a re-install. :)
Created attachment 106175 [details] Don't offer to delete the home directory if it is set to "/" The previous patch was against the wrong file.
Ouch. First my sincere apologies, this simply shouldn't happened. I think about fixing this like this (contains removing of left-over temporary files as well and not deleting logged in user, these are other bugs): - Totally refuse to remove system users (i.e. uid < 100 or user==nfsnobody) - warn if the user has processes running (could be the logged in user, I currently don't have an idea how to easily and reliably check for this, there is no trace in the environment about the user who originally started the config tool) - delete home directory only if it isn't owned by an RPM package - recursively delete any files/directories owned by the user in /tmp, /var/tmp - delete the user's mail spool if so desired (and actually owned by the user) All this after asking "Delete the user's files (home directory, mail spool, temporary files)?" of course.
- Totally refuse to remove system users (i.e. uid < 100 or user==nfsnobody) This wouldn't have prevented my oops as I created a user and didn't think to manually set the UID to < 100.
>uch. First my sincere apologies, this simply shouldn't happened. And no worries. Thanks.
Re comment #6, this is just an additional security measure and in fact it should be < 500, not < 100 ;-).
Yup. I see that. :) Unfortunatly for me, when I added the account for the daemon, I just let it pick a UID (and it picked 506). :) Is there something magic about UID < 500 (beyond this case) that I'm not aware of? (Other than convention, I mean?)
It's only convention. The tools should pick an available UID/GID >= 500 if you don't specify a different one.
An easy way to make errors like this at least somewhat less likely is to mention the home directory explicitly in the confirmation dialog.
Just say the updated system-config-users. Not deleting the home directory if it's not owned by the user being deleted is a really slick solution. You sir, are a steely-eyed missile man. :)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-440.html