/tmp contents?

[JLAIP]

My apologies in advance if some of these questions seem obvious, but I've been out of the BSD loop for many years and have been tasked with dealing with two old FreeBSD servers. Yes, I'm aware they're quite out-of-date, but they've been running without issue for many years (if it ain't broke...) and I don't have the time, knowledge or testicular fortitude to muck with proper upgrades considering the likelihood that I'd be causing problems where none currently exist simply to implement "best practices". That said...attached are screenshots of the /tmp contents of our email (pitcher) and web server (huntington), running BSD 4.11 and 6.3, respectively. In that context, I have a few questions:

1) Can someone point me to a man page or FAQ or describe what the various directories and files are in these /tmp directories; and, more importantly, whether they're innocuous, evidence of security issues and/or if they can be deleted without affecting anything? That is, unless needed for operation, I'd like to know which may be safely deleted.

2) What are the agent.xxx files in the ssh-* directories in /tmp, and can I delete them?

3) Both servers' /tmp directories contain the same four .*-unix directories, which appear to be empty. One of which, .X11-unix, appears to reference X Windows, which is NOT installed on either server. Are these referencing something other than X Windows?

4) Who is user "1004", or how do I find out?

 

[Beastie]

dealing with two old FreeBSD servers. Yes, I'm aware they're quite out-of-date [...] That said...attached are screenshots of the /tmp contents of our email (pitcher) and web server (huntington), running BSD 4.11 and 6.3

No, that's not out of date; that's literally museum material.

1) Can someone point me to a man page or FAQ or describe what the various directories and files are in these /tmp directories; and, more importantly, whether they're innocuous, evidence of security issues and/or if they can be deleted without affecting anything? That is, unless needed for operation, I'd like to know which may be safely deleted.

As hier(7) describes things, /tmp is used for storing "temporary files that are not guaranteed to persist across system reboots" as opposed to /var/tmp which is used for "temporary files that are kept between system reboots". In fact many people mount it as a tmpfs(5) and have it automatically cleared on reboots.
Most of these temporary file and directories are as old as the servers themselves and/or empty anyway.

2) What are the agent.xxx files in the ssh-* directories in /tmp, and can I delete them?

These are socket files used by ssh-agent(1). Normally they're deleted once the authentication agent's job is done. It's possible it crashed or something and it couldn't perform the clean up.

3) Both servers' /tmp directories contain the same four .*-unix directories, which appear to be empty. One of which, .X11-unix, appears to reference X Windows, which is NOT installed on either server. Are these referencing something other than X Windows?

It's used to store sockets for the communication between the Xorg server and its clients (WM, terminal, etc.) Perhaps at one time in the distant past X11 was installed.

4) Who is user "1004", or how do I find out?

cat /etc/passwd | grep 1004
id 1004

 

[JLAIP]

Many thanks, Beastie. This helps.
Still a coupla questions:
1. grep'ing passwd for "1004" returned nothing, yet there're several 1004s listed as the owner of some of the items in /tmp. Is "1004" one of the default BSD accounts or is there another source for these? I'd like to be able to mitigate (or rule out) the likelihood that "1004" is an "uninvited visitor".
2. I created both servers (20+ years ago) and X was never installed. So I remain confused as to how/why there'd be X references in /tmp?
3. Is it safe to delete ALL of the files/directories on /tmp on both servers, or are some of the items (e.g., those .*-unix directories that have recent dates) needed?

 

[rigoletto@]

3. Is it safe to delete ALL of the files/directories on /tmp on both servers, or are some of the items (e.g., those .*-unix directories that have recent dates) needed?

This is unsafe to run these versions at all...

Also, mandatory disclaimer: Topics about unsupported FreeBSD versions.

 

[ralphbsz]

1. grep'ing passwd for "1004" returned nothing, yet there're several 1004s listed as the owner of some of the items in /tmp. Is "1004" one of the default BSD accounts or is there another source for these? I'd like to be able to mitigate (or rule out) the likelihood that "1004" is an "uninvited visitor".

To my knowledge (which goes only ~10 years back with FreeBSD), 1004 has not been a user ID that's used by the default install. So 1004 was created by an admin at some point. If there is no 1004 in /etc/passwd, than it is not a current user, and can not log in or use files in any way.

Now, any file can have any ID number (both user and group). For example, I can do "chown 12345:54321 foo", and afterwards the file foo will be owned by user ID 12345 and group ID 54321, even though neither exists on my system. In and of itself, this is not a security problem if there is no process running with those IDs. Most likely, in the past the user 1004 did exist in the past, and this is a remnant.

The question is not: who is this user? But the important question is: Is this file still needed or useful?

2. I created both servers (20+ years ago) and X was never installed. So I remain confused as to how/why there'd be X references in /tmp?

Either X itself, or some other software that depends on X was installed at some point. Or someone copied these files from another system. Or someone hand-created them. Or something else. At this point, they are useless.

3. Is it safe to delete ALL of the files/directories on /tmp on both servers, or are some of the items (e.g., those .*-unix directories that have recent dates) needed?

Tough question. If all software running on this machine is well-behaved, bug-free, and up-to-date, then you can at a random point reboot the system, and completely clean out /tmp. That should work, since applications shall have no expectation that anything in /tmp survives a reboot.

However, given that the installed software on this machine is ~20 years old, the assumption of "well-behaved and bug-free" is laughable. In particular since it seems that there has been software running on this machine that has been forgotten (like X, or like whatever used user-ID 1004). Here is what I would do: Back up everything from /tmp to a safe place. The clean out /tmp and reboot. If everything works fine for an hour, day or week, then delete the backup. If something is broken, then find out which file you have to put back into /tmp from the backup.

Actually, my real advice is this: Invest only the minimum amount of time into maintenance of this machine, and as quickly as possible configure a replacement machines with current software. This thing is not maintainable with normal techniques; this is a museum piece.

 

[JLAIP]

To my knowledge (which goes only ~10 years back with FreeBSD), 1004 has not been a user ID that's used by the default install. So 1004 was created by an admin at some point. If there is no 1004 in /etc/passwd, than it is not a current user, and can not log in or use files in any way.
The question is not: who is this user? But the important question is: Is this file still needed or useful?

Yes, that IS the question. But I think it's now been answered.

Or someone copied these files from another system. Or someone hand-created them. Or something else.

Yes.

At this point, they are useless.

Good. Thank you!

Here is what I would do: Back up everything from /tmp to a safe place. The clean out /tmp and reboot. If everything works fine for an hour, day or week, then delete the backup. If something is broken, then find out which file you have to put back into /tmp from the backup.

Considering the options, I think that'll have to be the plan.
Many thanks again!

 

[JLAIP]

This is unsafe to run these versions at all...
Also, mandatory disclaimer: Topics about unsupported FreeBSD versions.

Noted and thank you for the reply.

 

[SirDice]

These directories are created automatically, even if you've never installed Xorg:

drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .ICE-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .X11-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .XIM-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .font-unix/

Have a look in /etc/rc.d/cleartmp:

        # X related directories to create in /tmp.
        local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \
                               ${tmp}/.ICE-unix ${tmp}/.font-unix"

Regarding question #2, see ssh-agent(8).

 

[JLAIP]

These directories are created automatically, even if you've never installed Xorg:

drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .ICE-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .X11-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .XIM-unix/
drwxrwxrwt  2 root  wheel   0 Feb 16  2019 .font-unix/

Have a look in /etc/rc.d/cleartmp:

Interestingly, neither the directory, /etc/rc.d, nor the file, cleartmp, exists on the webserver (running 4.11). But it is on the email server (running 6.3). Odd that both servers have those four directories in /tmp (with recent dates). But point taken. Since they're all empty, they must be placeholders that get cleared regularly, so I'll leave them.

Regarding question #2, see ssh-agent(8).

Thank you.

 

[olli@]

Interestingly, neither the directory, /etc/rc.d, nor the file, cleartmp, exists on the webserver (running 4.11). But it is on the email server (running 6.3). Odd that both servers have those four directories in /tmp (with recent dates).

In ancient times, most of the things that are done by /etc/rc.d/* scripts today were performed by the /etc/rc script, including clearing and initializing /tmp.

By the way, the proper way to handle a machine running FreeBSD 4.11 or 6.3 is to disconnect it from the internet immediately, and only reconnect it when you upgraded to a supported FreeBSD version that cannot be hacked and abused by script kiddies within ten seconds.