Opened 11 years ago

Last modified 6 years ago

#138 assigned Bug/Something is broken

Files on MFPL servers with no user and/or no group

Reported by: https://id.mayfirst.org/dkg Owned by: https://id.mayfirst.org/jamie
Priority: Medium Component: Tech
Keywords: file ownership cleanup Cc:
Sensitive: no

Description

Some MFPL servers (particularly the shared hosts, i think), have many files "owned" by uids or gids which are not listed in $(getent passwd) or $(getent group), respectively. This is a problem for several reasons:

  • it's unclear who is responsible for these files
  • the vacant uids and gids may at some point be reassigned to a new account. That account would then inherit these files, with unpredictable results
  • a reasonable regular security scan would be to look for unusual files like these, which might indicate root-level tampering with the system. Leaving "harmlessly" mis-owned files around like this would obscure the results of such a scan.

I can think of three ways such files could be commonly created by accident:

  • a user account creates files, and is then removed. the old files linger.
  • someone unpacks a tarball or zipfile while running as superuser, and asks to create with ownership as stored in the archive.
  • a system service/package installation script creates a system user, and the service creates files that are owned by that user. The package is later removed, and the system user is removed with it. (i'm not sure if this ever happens)

There are other, nastier ways that these files could have been created. i'd like to think that those are unlikely at the moment.

Two servers where it seems to be a particular concern. These counts only measure files which a non-privileged user has access to, so the real numbers may be greater):

[0 dkg@malcolm ~]$ find / -nouser -or -nogroup 2> /dev/null | wc -l
612
[0 dkg@malcolm ~]$ 
[0 dkg@viewsic ~]$ find / -nouser -or -nogroup 2> /dev/null | wc -l
40549
[0 dkg@viewsic ~]$ 

I haven't done full scans of every server.

Change History (7)

comment:1 Changed 11 years ago by https://id.mayfirst.org/dkg

Any word on this?

comment:2 Changed 11 years ago by https://id.mayfirst.org/jamie

I was just working on this earlier this afternoon and left the find command running (and forgot about it). I made a dent on the files in viewsic:

0 jm@viewsic:~$ find / -nouser -or -nogroup 2> /dev/null | wc -l
22074
0 jm@viewsic:~$

I'm going to try to take this a little bit every week. It's a pretty tedious chore.

comment:3 Changed 11 years ago by https://id.mayfirst.org/dkg

What are you doing to fix this? Maybe if you explained your strategy, other folks with admin privileges could help chip away at the tedium.

comment:4 Changed 11 years ago by https://id.mayfirst.org/jamie

I've mostly been deleting loads of files that I happen to know (given my history with the box) can be deleted. And, the remaining ones I have been chowning either to root (for the ones locate in /usr/local/share) or to the rightful owner when that's apparent (i.e., if it shows up in a directory in each the other files and directories parallel to it is owned by a reasonable user.

comment:5 Changed 11 years ago by https://id.mayfirst.org/dkg

ah, deleting is good!

fwiw, the files on malcolm look pretty easy. they're only in 3 directories (plus a squirrelmail gpg plugin), which should make it quick to knock that server down to 0. I notice that a big chunk of the malcolm files visible to a non-priv user are in root's CPAN build tree. What's the policy on CPAN-built packages installed by the superuser on MF/PL hosts? problems with package dependencies can be tricky when mixing and matching CPAN and debian, esp. when it comes to a "stable" release. I tend to think of CPAN as comparable to debian unstable (or maybe leading unstable a little bit).

How do you determine that mis-owned files are actually properly owned by the "rightful owner" if that user should never have had the privileges to create those files in the first place?

comment:6 Changed 6 years ago by https://bugmagnet.myopenid.com/

  • Resolution set to fixed
  • Status changed from new to closed

I must assume this has been attended to, but if not and there remains some concern, perhaps the files can be locked away for a period and if no one claims them then it may be time to purge and recover the space.

comment:7 Changed 6 years ago by https://bugmagnet.myopenid.com/

  • Resolution fixed deleted
  • Status changed from closed to assigned

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.