Since the mail/dovecot port doesn't delete /var/empty as part of the package removal, I don't think this can be considered a bug.
rmuser -y dovecot so that all confirmations were assumed yes? chflags schg /var/empty, which will ensure the directory cannot be deleted in future without unsetting the flag. ls -lod /var/empty. Can you recreate an issue where the schg flag isn't set during the installation? Or where the flag is ignored when there is an attempt to delete a directory marked as immutable?
It doesn't. Removing the package doesn't remove the account(s). It only suggests to remove the accounts if they're not needed any more. The actual removal is left up to you to do. So it was you that should have verified if the set home directory was still required. Just as you had to verify you really didn't need those accounts any more. You basically shot yourself in the foot, and the system won't stop you from doing that. Just as it won't stop you from nuking your system by doing a
rm -rf /.
In 999 out of 1000 times, yes, it is.
It can't tell, it doesn't know. And what if I want to remove the account a few days later? You've used rmuser(8) but what about pw(8)? And a few other ways of account management? What if NIS or LDAP is involved?
What if you know it's not used any more and still want to remove the home directory?
How would it be able to figure this out?
So, we need to keep track of which service uses what directories? How would the application know it's used by something else?
I'm sorry you feel that way, frijsdijk. My experience of the forums has been that there is much to be gained from the collective knowledge of people here, the vast majority of whom are trying only to help fellow FreeBSD users.
So either there's a bug in rmuser which made it remove the directory regardless of the owner or the OP made a mistake here. I can't reproduce any issues on 12.1. Note that I'm not trying to rub anything in here, but since the OP repeated the possible fix of checking the home directories ownership... yah, it seems rmuser already does that:
root@magi:/home/peter # ls -ld /var/empty
dr-xr-xr-x 2 root wheel 2 Dec 7 2018 /var/empty
root@magi:/home/peter # rmuser testor
Matching password entry:
testor::1002:1002::0:0:The Test:/var/empty:/bin/sh
Is this the entry you wish to remove? y
Remove user's home directory (/var/empty)?
Remove user's home directory (/var/empty)? y
Removing user (testor): mailspool home passwd.
root@magi:/home/peter # cd /var/empty
root@magi:/var/empty # cd ..
root@magi:/var # ls -ld empty
dr-xr-xr-x 2 root wheel 2 Dec 7 2018 empty
root@magi:/var #
[root@progress ~]# id testuser
uid=6060(testuser) gid=6060(testuser) groups=6060(testuser)
[root@progress ~]# grep testuser /etc/passwd /etc/group
/etc/passwd:testuser:*:6060:6060:test user:/var/empty2:/usr/sbin/nologin
/etc/group:testuser:*:6060:
[root@progress ~]# ls -ld /var/empty2
dr-xr-xr-x 2 root wheel 2 Mar 18 09:22 /var/empty2
[root@progress ~]# rmuser testuser
Matching password entry:
testuser:*:6060:6060::0:0:test user:/var/empty2:/usr/sbin/nologin
Is this the entry you wish to remove? y
Remove user's home directory (/var/empty2)? y
Removing user (testuser): home passwd.
[root@progress ~]# grep testuser /etc/passwd /etc/group
[root@progress ~]# ls -ld /var/empty2
ls: /var/empty2: No such file or directory
[root@progress ~]# uname -r
11.3-RELEASE-p5I appreciate that. And for the record, despite my cynical comment above I'm on the same page as asteriskRoss on this one: I also think it would be a shame if you were to leave because of one bad experience.
rmuser(8) is a shell script that calls pw(8) with userdel -r. According to the man page, pw(8) is supposed to "only remove files and directories that are actually owned by the user, or symbolic links owned by anyone under the user's home directory." However, I looked at the code, and it seems to me that the ownership check is done only on files, and not on directories.void
rm_r(int rootfd, const char *path, uid_t uid)
{
int dirfd;
DIR *d;
struct dirent *e;
struct stat st;
if (*path == '/')
path++;
dirfd = openat(rootfd, path, O_DIRECTORY);
if (dirfd == -1) {
return;
}
d = fdopendir(dirfd);
while ((e = readdir(d)) != NULL) {
if (strcmp(e->d_name, ".") == 0 || strcmp(e->d_name, "..") == 0)
continue;
if (fstatat(dirfd, e->d_name, &st, AT_SYMLINK_NOFOLLOW) != 0)
continue;
if (S_ISDIR(st.st_mode))
rm_r(dirfd, e->d_name, uid);
else if (S_ISLNK(st.st_mode) || st.st_uid == uid)
unlinkat(dirfd, e->d_name, 0);
}
closedir(d);
if (fstatat(rootfd, path, &st, AT_SYMLINK_NOFOLLOW) != 0)
return;
unlinkat(rootfd, path, S_ISDIR(st.st_mode) ? AT_REMOVEDIR : 0);
}else if clause. Subdirectories are removed with recursive calls to rm_r in the preceding if clause. Ultimately, a directory is removed by the call to unlinkat at the bottom of the function, where there is no check performed. unlinkat will fail if a directory is non-empty, however./var/empty is protected with the schg flag:root@bluejay:~ # ls -dlo /var/empty
dr-xr-xr-x 2 root wheel schg,uarch 2 Nov 1 00:25 /var/emptypw(8) should probably be fixed, nevertheless./var/empty being removed. It's a combination of a bug in pw(8) that manifests only in singular circumstances, and a machine history unusual enough to create those conditions.Keep in mind that we're all users here. You need to sent in an official bug report to get the gears moving, as ehanneken already mentioned above.
Confirmed! And nicely spotted too, here's my follow up:
"Not good", because testor doesn't seem to match root last I checked.