# [Solved] /tmp/.private - usefull and why can't I delete it?

## avx

I'm posting this here, cause I don't know, if it's security related, please move if neccessary!

Hello,

I've just finished a new installation (~amd64), rebooted and am getting an error at boot:

 *Quote:*   

> find: can't remove /tmp/.private/ph030 : operation not permitted
> 
> find: can't remove /tmp/.private/root : operation not permitted
> 
> find: can't remove /tmp/.private : operation not permitted

 

I guess, this is the result of some init-script trying to wipe /tmp.

The question is, what made this directories (they are empty) and what are they good for - or are they even bad?

```
ph .private # LC_ALL=C ls -l

total 0

drwxrwx--T 2 root root 6 Mar 24 01:08 ph030

drwx-----T 2 root root 6 Mar 23 16:59 root

LC_ALL=C rm -rf *

rm: cannot remove directory `ph030': Operation not permitted

rm: cannot remove directory `root': Operation not permitted
```

```
ph tmp # LC_ALL=C ls -lA

total 4

-r--r--r-- 1 root  ph030 11 Mar 23 17:07 .X0-lock

drwxrwxrwt 2 root  root  15 Mar 23 17:07 .X11-unix

drwx--x--x 4 root  root  29 Mar 23 12:34 .private

drwx------ 2 ph030 ph030  6 Mar 23 17:27 vmware-ph030
```

I can `chown` them as root, but can't delete them.

thanks for your help,

phLast edited by avx on Tue Mar 25, 2008 5:10 am; edited 1 time in total

----------

## Sadako

Try chmod first, ie `chmod -R 0775 /tmp/.private`, then see if you can delete them.

----------

## avx

Thanks for your answer, but unfortunately, it fails...

```
ph tmp # LC_ALL=C chmod -R 0775 /tmp/.private/

chmod: changing permissions of `/tmp/.private/': Operation not permitted
```

Edit, just for "safety", I ran chkrootkit which found nothing, also scanning&listening with nmap&wireshark from another box doesn't reveal anything suspicious.

----------

## tarpman

Run a filesystem check.

----------

## Sadako

A quick google suggests the directories where created by pam, and the reasons you can't change them may be due to the use of extended attributes in the filesystem.

What does `lsattr -da /tmp/.private` and `lsattr -Ra /tmp/.private` return?

----------

## avx

@tarpman, thanks but that didn't help

@hopeless

```
ph ~ # LC_ALL=C lsattr -da /tmp/.private

-----a-------- /tmp/.private
```

```
ph ~ # LC_ALL=C lsattr -Ra /tmp/.private

-----a-------- /tmp/.private/.

-------------- /tmp/.private/..

-------------- /tmp/.private/root

/tmp/.private/root:

-------------- /tmp/.private/root/.

-----a-------- /tmp/.private/root/..

-------------- /tmp/.private/ph030

/tmp/.private/ph030:

-------------- /tmp/.private/ph030/.

-----a-------- /tmp/.private/ph030/..
```

Edit, /tmp is a XFS-partition, create with `mkfs.xfs /dev/foo`, "XFS POSIX ACL support" is enabled in the kernel.

----------

## timeBandit

Does lsof /tmp/.private show the directories are in use by anything?

----------

## Sadako

The "a" in the lsattr output (apparently) means "append only", so try `chattr -R -a /tmp/.private` and see if you can remove them then.

----------

## avx

@timeBandit, I did try that before - forgot to mention, sorry - but it showed nothing.

I ran some tests and stepped trough some more logs, which showed that VMware made use of this directory, but it's also been there before, so I guess it's usefull for something.

@Hopeless, thank you, that's working.

So, since this dir is used by some legal applications, I guess it doesn't harm and so maybe we should consider this a bug in the /tmp-wiping init-script? Do you guys mean that this behaviour should be reported or is this how it's been intended and I just have known too little, as I'm just starting to experiment with ACLs?

thanks again,

ph

PS: I'm marking this [Solved].

----------

