Bug 138093 - Should not delete directories outside of /home
Summary: Should not delete directories outside of /home
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-users (Show other bugs)
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-04 16:25 UTC by Mark Levitt
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-11 10:25:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Don't offer to delete the home directory if it is set to "/" (589 bytes, patch)
2004-11-04 16:29 UTC, Mark Levitt
no flags Details | Diff
Don't offer to delete the home directory if it is set to "/" (615 bytes, patch)
2004-11-04 17:16 UTC, Mark Levitt
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:440 low SHIPPED_LIVE Updated redhat-config-users package 2005-05-19 04:00:00 UTC

Description Mark Levitt 2004-11-04 16:25:09 UTC
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):

How reproducible:

Steps to Reproduce:
1. Create an account.
2. Set the "Home Directory" fiels to "/" (as it is for an account like
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:

Comment 1 Mark Levitt 2004-11-04 16:29:25 UTC
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.

Comment 2 Elliot Lee 2004-11-04 16:32:09 UTC
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.

Comment 3 Mark Levitt 2004-11-04 16:41:29 UTC
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. :)

Comment 4 Mark Levitt 2004-11-04 17:16:03 UTC
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.

Comment 5 Nils Philippsen 2004-11-04 17:27:38 UTC
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
- 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,
- 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.

Comment 6 Mark Levitt 2004-11-05 10:30:19 UTC
- Totally refuse to remove system users (i.e. uid < 100 or

This wouldn't have prevented my oops as I created a user and didn't
think to manually set the UID to < 100. 

Comment 7 Mark Levitt 2004-11-05 10:31:39 UTC
>uch. First my sincere apologies, this simply shouldn't happened.

And no worries. Thanks.

Comment 8 Nils Philippsen 2004-11-05 15:05:55 UTC
Re comment #6, this is just an additional security measure and in fact
it should be < 500, not < 100 ;-).

Comment 9 Mark Levitt 2004-11-05 15:11:34 UTC
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?)

Comment 10 Nils Philippsen 2004-11-05 15:44:28 UTC
It's only convention. The tools should pick an available UID/GID >=
500 if you don't specify a different one.

Comment 11 Miloslav Trmač 2004-11-06 23:33:40 UTC
An easy way to make errors like this at least somewhat less likely
is to mention the home directory explicitly in the confirmation dialog.

Comment 12 Mark Levitt 2004-11-10 18:23:19 UTC
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. :)

Comment 13 Tim Powers 2005-05-19 21:39:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.