# kernel bug with special attribs -> ~ got write-protected?!

## ExecutorElassus

NOTICE TO NEW READERS: check the last post i've posted, as the situation is somewhat changed from this initial post.

So, i'm writing this in freaking LYNX, because no other 

browser will work. Why, you ask? because, when i started X, i got this:

```
xauth: timeout was reach when trying to lock file /home/elassus/.Xauthority
```

not being sure what that meant, i went into X, and discovered that NOTHING in my ~ can be written.

by anybody! not even ROOT can write to that directory, nothing that needs to write temp files (say, any KDE app that needs to write a socket file, or write any kind of tmp file, or anything), and no programs.

it royally sucks, and i'm not sure what the error is. i just recently emerged a bunch of stuff as part of a regular emerge (-puD world about every three days).

i did emerge -C csh, but i have tcsh in there (maybe it's a problem with a security daemon?).

anyway, this really sucks, and i'd much appreciate whatever help i can get.

thanks a lot!

EELast edited by ExecutorElassus on Thu Feb 16, 2006 4:32 am; edited 3 times in total

----------

## patroy

is this the same for all users? or just this one?

----------

## ExecutorElassus

only this user, and only this user's ~ directory (and everything under it). incidentally, here's some other weird behavior:

if i mount another partition to a subdirectory, i can create and delete files.

in a (non-mounted) subdirectory of ~, i can only create files, not delete them.

this same behavior applies when i su to root.

thanks for the help!

EE

----------

## patroy

OK so I don't use KDE but i imagine that this would hold true for that enviroment as well. I've had a similar issue before and I just fixed it the dirty way. 

I backed everything up in the ~ and removed the user and the ~ and recreated them both. Then tested the config files to find the culprit by replacing the new with the old one at a time...

There probably is a better way. But I figure if it works and it's safe do it.

----------

## nephros

Okay a couple of questions:

What are the permissions for /home and /home/thatuser?

Is either of those on an extra partition? If yes, what filesystem and mount options are you using?

Is it a fresh install? What install media and stage tarball did you use if yes?

----------

## ExecutorElassus

let me reiterate a few things:

this is not a fresh install (see first post)

NOBODY can delete ANYTHING in /home/myname, not even root (so i can't do a backup/restore action).

this is not a separate partition, and it is still mounted rw, and all the permissions on all the files and directories appear correct.

i cannot do anything even when X isn't running (ie, even root can't delete a file in /home/myname from the console).

c'mon guys, i'm not such a newbie. and i've already ansered most of your questions in previous posts.

anyway, thanks,

EE

----------

## madchaz

What are the permisions on the folder?

700? 000?

You could try booting off the liveCD and see if you can't change the permisions on the folder to 700 with chmod -R 700 /home/youruser

See after that if you can't do anything still. Then try it again once booted to the system. [/code]

----------

## ExecutorElassus

also: i cannot mount the partition containing /home from the livecd. it's a reiserfs partition, on a scsi drive. 

and i don't appear able to change permissions on anything on it, either (though they look correct anyway). 

but also: i noticed that - at the same time that i lost write permissions on this folder - that changing user permissions (ie, using su) takes WAY longer than it used to. 

i also ran reiserfsck on the disk, just in case, to no avail.

anyway, i'll see if i can do anything more with the livecd.

i should also mention this: any time i try to delete a file in /home/myhome/, i get the question: "rm: remove write-protected regular file: 'file'?" how do i tell if a file is write protected? or, for that matter, if the filesystem is set up as write protected? is there something in reiserfsprogs that can change this? i seriously don't think this is anything to do with permissions or ownership, as both are still listed correctly (and what config file could change permissions on EVERY file in a directory, anyway?). i suspect that it's something to do with the reiser filesystem, but i'm not sure what yet. anybody got any ideas?

thanks,

EE

EDIT: later:: can't mount the partition in question from the liveCD, because the stock kernel on the liveCD doesn't appear to support mounting reiser partitions (??)

----------

## ExecutorElassus

And here's another thing: when i ran openoffice, and tried to save a file (to one of my other partitions, onto which i can still write) it hung on me, and strace gave the following message:

```
futex(0x80c05c8, FUTEX_WAIT, 2, NULL <unfinished ...>
```

i did a little reading on futextes, and i don't understand why oo2 would be hanging on one to save a file. is there any way to debug this a little better?

i've now narrowed the overall problem down a bit: it's only the directory /home/myname, and all subdirectories on that partition. if i mount something to a subdirectory from a different partition, i can still write to it with no trouble. but NOBODY can alter files (delete, add, or touch) on /home/myname. all other user directories are fine, too.

hope this helps explain the problem a bit.

thanks,

EE

----------

## XenoTerraCide

there is a file permission that makes files unalterable just like your talking about. I'm gonna see if I can't find it and how to change it. It may be your problem.

----------

## XenoTerraCide

found it  *Quote:*   

> chattr
> 
>     Change file system attributes (works on ext2fs and possibly others...). Use the -R option to change files recursively, chattr has a large number of attributes which can be set on a file, read the manual page for further information.
> 
>     Example:
> ...

  here's my source http://www.karakas-online.de/gnu-linux-tools-summary/security.html plenty of file permission stuff there. let me know if it helps.

----------

## ExecutorElassus

XenoTerraCide is my own personal jesus. that fixed it, though how my /home got the +i set, i have no idea. at least now i can write to the directory.

now. i'm trying to clean up, and i notice that i have a bunch of broken links in my .kde directory (pointing to tmp files which no longer exist), and i cannot delete them, even as root. any idea how to fix that?

thanks for this help. i was totally stuck.

EE

----------

## XenoTerraCide

I have no idea how it would have gotten set either. did you check to make sure those don't have the immutable flag? might want to run a

```
chattr -R -i /home
```

 that should recursively unset the immutable flag in your entire home directory.

----------

## XenoTerraCide

if you don't have any clue how this happened I would recommend scanning your entire system for a virus with clamav. unless you have another preference for a linux virus scanner. because I can think of no reason for this to happen. also tighten your security does anyone else have access to this computer? do you run telnet, ssh, or other app that would allow someone to make a remote connection?

----------

## ExecutorElassus

i'm behind a firewall, with explicit port forwarding. there are no telnet/ssh-type programs with ports open to the outside. 

i'm running clamscan now, though it's frustratingly slow. 

there are still some problems with the system: i can't start any kde programs (kmail says it can't bind to a socket, becaust it's 'already in use'). and check this:

```
Wed Feb  8 22:25:07 EST 2006

~/Documents elassus@ukiyo: pts/3: 18 files 3.0Mb $ mkdir foo

Wed Feb  8 22:42:32 EST 2006

~/Documents elassus@ukiyo: pts/3: 21 files 3.3Mb $ ls -l foo*

drwxr-xr-x 2 elassus users      48 Feb  8 22:25 foo

Wed Feb  8 22:25:50 EST 2006

~/Documents elassus@ukiyo: pts/3: 20 files 3.1Mb $ rmdir foo

rmdir: foo: Operation not permitted
```

any idea how THAT happens?

i'm flummoxed. and kde is still nonfunctional, and openoffice won't start. clamscan only found a couple email viruses, which have no import. however, i think the problem is also this: the system crashed a couple times, and i suspect that the journaling function screwed some things up. but i don't know how to fix them. the most difficult ones i have right now are kde, and the problem of oddly undeletable files.

i should also add this: when i went into one subdirectory (one where there were three virus files) and ran 'lsattr' (thanks for the security link, by the way!) i got TONS of weird attributes on files (the ones in that directory had the following flags:

adjstuADIT

i have NO idea what the I flag is (it's not in the chattr listing), but i had to remove all the rest before i could delete the files. how did some obscure subdirectory with a noatun skin get that many special attributes on it? the viruses it found, incidentally, are this:

./.wine/fake_windows/Program Files/KaZaA Lite/Kazaa.exe: Worm.Bagle.BB-gen FOUND

./.wine/fake_windows/Program Files/KaZaA Lite/KazaaLite.kpp: Worm.Bagle.BB-gen FOUND

./.kde.backup/share/apps/noatun/skins/kjofol/CrystaLPlanet1-00/Crystal_Planet.zip: Oversized.Zip FOUND

./.mozilla/elassus/kzqls556.slt/Cache/88E3CA11d01: Worm.SomeFool.Gen-1 FOUND

./Downloads/widgets/noatun/CrystaLPlanet1-00.zip: Oversized.Zip FOUND

./Downloads/widgets/noatun/236-steel_forged_1.1.zip: Oversized.Zip FOUND

and check this:

```
 #rm /home/elassus/Downloads/widgets/noatun/236-steel_forged_1.1.zip 

rm: cannot remove `/home/elassus/Downloads/widgets/noatun/236-steel_forged_1.1.zip': Operation not permitted

# lsattr /home/elassus/Downloads/widgets/noatun/236-steel_forged_1.1.zip 

su---a-Acj-t- /home/elassus/Downloads/widgets/noatun/236-steel_forged_1.1.zip
```

more wacky attributes!

any guesses what's going on? these files have been there for years.

thanks,

EE

----------

## XenoTerraCide

I wonder if you've managed to get some existing linux virus (rare) or even worse... maybe there is a new one. if you haven't deleted anything don't. get on irc and talk to the folks at clamav  *Quote:*   

>  /server irc.freenode.net
> 
> /join #clamav
> 
> 

   *Quote:*   

> An unofficial IRC support channel ran by volunteers is available on irc.freenode.net.

  tell them what happened give them your result's and see what they think. I doubt a journal screwed things up. what filesystem is it? ext3? you could boot to the livecd and run an fsck. I would prefer to rule out a virus (or related like a worm) first. if it's possible we need to know before it spread's to the rest of the community. I hate seeming paranoid because I know it's unlikely that, that's the cause. I'll say that I'm really not that knowledgable about these sort of things.

 I only knew about the immutable flag because I read about it somewhere once (I think my linux+ book) and when you said you could't delete stuff I thought of that. It maybe something to do with a journal, but I've never heard of such a thing. Maybe you should change the subject of this thread to include something like 'possible linux virus' and see if we can attract attention. I'll be happy to be way off base, but you have a weird issue. 

Another possibility Is that your partition is setting these flags by default on all new files. A journal replay may appear to be a new file thus setting old files.

----------

## ExecutorElassus

the directory in question is reiserfs, so i can't check it from the liveCD. 

the people on the clamav channel aren't being too helpful, so i'll see if changing the topic gets any attention. 

i only have a couple directories that still don't work, but they're annoying ones (.opera and .kde and the bin directory for my cookie/ad blocker). 

here's the situation, now: i have several directories that - for whatever reason - channot have their contents changed in any way, even by root. what i want to know is:

1)how did they get that way? permissions and ownership and special arrtibutes are all unchanged.

2)how do i fix them, knowing 1) above?

thanks,

EE

----------

## taipan67

Well, the change in heading certainly attracted my attention, though i don't know if i can be of any help...

You've said that you can't fsck your partition from a LiveCD because it's reiserfs; This shouldn't be a problem, as every CD i know of supports it, so i'd like to ask if you mean reiser4, which isn't supported by many CD's.

If that's the case, it might be where the problem lies, as (last i heard) reiser4 was still a bit unstable...   :Confused: 

----------

## ExecutorElassus

nope, this is an old reiser partition.

when i try to mount it from the livecd, it says i have to specify the fs type.

then it says it can't mount it.

EE

----------

## taipan67

I'm a bit pissed right now, so i apologise if i've got this completely wrong, but does it have to be mounted to be fsck'd? Can't you fsck the unmounted 'device'?

```
fsck /dev/hda3
```

...or something like that?

----------

## ExecutorElassus

fsck found nothing. i figured out why it wasn't mounting: something wrong with the modules, and the livecd wasn't loading the scsi modules i needed to mount it.

anyway, there's nothing wrong with the partition, near as i can tell. my ~ is the only directory affected anyway.

thanks,

EE

----------

## ExecutorElassus

but let's try a different problem, since the undeletable files problem seems stubborn.

i have a bunch of socket files in my .kde/socket-hostname/ directory. i can't delete them, and whenever i try to start a kde app (say, kmail), i get this:

```
 $ kmail

kdeinit: Aborting. bind() failed: : Address already in use

Could not bind to socket '/home/elassus/.kde3.3/socket-ukiyo/kdeinit__0'

ERROR: KUniqueApplication: Can't setup DCOP communication.

```

am i correct in thinking that this is because of these socket files, or is there some other reason for this problem? 

can anybody help me fix this one?

thanks,

EE

----------

## taipan67

 *ExecutorElassus wrote:*   

> ...but let's try a different problem...

 

On my KDE-3.4 installation, that directory is a symlink to a sub-directory of /tmp, it's ownership is correct for my username:group, & the specific socket mentioned is mode 600...

...So, without actually trying to delete it, i'd say it's the same problem. Can it be fixed with 'chattr'?   :Confused: 

----------

## XenoTerraCide

if the symlinks are to directories make sure you arent't trying to delete them as directories. 

```
rm blarg/
```

will not work if blarg is a symlink you have to 

```
rm blarg
```

 to delete it.

----------

## ExecutorElassus

in my .kde/, the ksocket directories are broken links, pointing to a directory in tmp that doesn't exist. however, those directories STILL have files in them (??). 

i can't delete the files, so i can't remove the directory. once i make the directory in /tmp, the link is correct, but it's still populated with all the undeletable socket files.

this is kde-3.5.1.

thanks,

EE

----------

## Gergan Penkov

Well could you delete the files from the live-cd? there was sth about acl, extended attributes and so on, which implements such readonly behaviour (it is taken from *bsd if i remember this right) - which says that after changing some kernel attribute at start you are not allowed to change it back any more and if on start you are setting (or some script) this in the kernel - you will be in this situation.

----------

## taipan67

 *ExecutorElassus wrote:*   

> ...this is kde-3.5.1...

 

...But in your first post regarding the sockets, the code-snippet refers to...

```
Could not bind to socket '/home/elassus/.kde3.3/socket-ukiyo/kdeinit__0'
```

...Is that a typo, or does KDE mix 'n' match these directory-names? (I'm not trying to be funny - i was a confirmed gnome-user until recently, so i've only used version 3.4, & never upgraded.)   :Shocked: 

----------

## cobralgato

I had this same problem(the one which is at the beggining of the thread) two days  ago and solved it  using the root acount moving some files out of the gentoo partition( it was full  :Razz: ) and then doing a emerge -u world...

----------

## ExecutorElassus

Penkov: i'll try deleting files from the liveCD later tonight, and let you know what happens. do you remember what kernel attribute was set? i'm pretty sloppy about setting up my kernel configs (i usually just copy the previous one), so it's possible something slipped in. but why does it only affect my home directory?

taipan67: kde, apparently, does mix-n-match. the .kde/ directory is itself a symlink to .kde3.3/. there is no .kde3.4 or 3.5. 

cobralgato: which files did you move out of which partition? none of my partitions are full, though.

and while we're at it, all this happened when i was upgrading from 3.5.0 to 3.5.1. the computer crashed a couple times in the middle of the emerge (unrelated cause, though), and so kdelibs had to get restarted a couple times. 

i'll report back in a few hours.

thanks,

EE

----------

## ExecutorElassus

Penkov: what was that kernel option? i could delete those files from the livecd, so it must be something with the kernel.

can you let me know how to fix that?

thanks,

EE

----------

## XenoTerraCide

http://linux.about.com/library/cmd/blcmdl5_acl.htm that will explain acl somewhat. um... if you search google for it make sure you either use the linux search or have linux in the keywords because apparently it is also medical terminology.

----------

## Gergan Penkov

Well I'm not sure what's its name on linux, but here is a reference on it for *bsd http://geodsoft.com/howto/harden/OpenBSD/no_changes.htm#chflags

and how it functions.

I have read that this exist on linux, but I don't know what the specific commands are and how to turn it on or off:(

But single user mode should be ok in order to recover the attributes of this directory:)

----------

## ExecutorElassus

well, i appear to have libacl.h in my includes, so i'll dig into the kernel tomorrow, and see what happens. 

thanks for the tips on this; i was really going out of my mind.

EE

----------

## ExecutorElassus

so, i read a bit about ACLs. now check this:

```
$ getfacl Documents/foo       

   # file: Documents/foo

   # owner: elassus

   # group: users

   user::rwx

   group::r-x

   other::r-x

$ rmdir Documents/foo

rmdir: Documents/foo: Operation not permitted
```

seems like the default ACL is okay; at least, the perms seem like they SHOULD allow me to delete this file. 

in my current kernel config, i'm using something called "Default Linux Capabilities" under the security options. i selected the POSIX ACL capability for both ext3 and reiser, just in case something wasn't working with those being unselected.

anyway, we'll see what happens. i still can't start a kde app, though now it gives me something different to crash:

```
$ kmail

kbuildsycoca running...

kbuildsycoca: WARNING: '/usr/kde/3.5/share/applications/kde/ark.desktop' specifies undefined mimetype/servicetype 'application/x-tbz2'

kbuildsycoca: WARNING: 'ark_part.desktop' specifies undefined mimetype/servicetype 'application/x-tbz2'

kbuildsycoca: WARNING: 'karm_part.desktop' specifies undefined mimetype/servicetype 'text/english'

kbuildsycoca: WARNING: 'karm_part.desktop' specifies undefined mimetype/servicetype 'text/x-c'

kbuildsycoca: WARNING: 'karm_part.desktop' specifies undefined mimetype/servicetype 'text/x-c++'

kbuildsycoca: WARNING: 'klinkstatus_part.desktop' specifies undefined mimetype/servicetype 'text/english'

kbuildsycoca: WARNING: 'klinkstatus_part.desktop' specifies undefined mimetype/servicetype 'text/x-c'

kbuildsycoca: WARNING: 'klinkstatus_part.desktop' specifies undefined mimetype/servicetype 'text/x-c++'

kbuildsycoca: WARNING: '/usr/share/applications/gimp-2.0.desktop' specifies undefined mimetype/servicetype 'image/bmp'

kbuildsycoca: WARNING: '/usr/share/applications/gimp-2.0.desktop'

etc...

...DCOP aborting (delayed) call from 'anonymous-5912' to 'kmail'

ERROR: Communication problem with kmail, it probably crashed.

KCrash: Application 'kmail' crashing...

```

i guess we're making progress...

please let me know what else it might be, or if i just don't understand ACLs well enough yet.

thanks,

EE

----------

## Gergan Penkov

 *Quote:*   

> i'm using something called "Default Linux Capabilities"

  in fact this was what I meant,

well I found it now - 

```
man capabilities
```

and this 

 *Quote:*   

>        CAP_LINUX_IMMUTABLE
> 
>               Allow   setting  of  the  EXT2_APPEND_FL  and  EXT2_IMMUTABLE_FL
> 
>               extended file attributes (see chattr(1)).

 

so if you or virus or some buggy program has set the extended file attributes in some way to immutable and after that you have restarted and this flag is not set from the init scripts you will have no way to change the attributes or to modify the files/dirs. Probably the live-cd caps all the attributes in order to make life easier I don't know - but it looks like this is the problem.

----------

## salahx

I don't think its a virus, rather a Linux kernel bug. THis patched backs out automatically enabling attributes on residerfs filesystems:

http://lkml.org/lkml/2006/2/12/76

Dsiovered as a result of these threads

http://lkml.org/lkml/2006/2/8/38

http://lkml.org/lkml/2006/2/10/361

http://lkml.org/lkml/2006/2/12/99

The easiest way to fix is to clear all the attributes on the reiserfs filesystem, by:

```

reiserfsck --clean-attributes <device>

```

If it is your rootfilesystem, you'll need to boot from a LiveCD first, of course !

----------

## XenoTerraCide

Interesting. I thought a virus because I doubted a kernel or filesystem bug. Someone had suggested to me possible hardware issue's as well but I doubt that because that should affect more than one directory. I told him to change it knowing it would get more publicity that way and it was acting like some viruses do (in windows) even though I knew this was unlikely. I'm glad I'm wrong.

----------

## Gergan Penkov

Awsome  :Smile: 

I'm glad I've changed all my reiserfs partitions some time ago  :Smile: , although this could happen with ext3 also  :Sad: 

----------

## ExecutorElassus

you guys have been temendous help: i rebooted into a kernel that had the extended attributes flags on for reiserfs, and then ran 'reiserfsck --clean-attributes' on the partition. now i can get most things (kde apps, my cookie blocking proxy, etc.) to work.

now, though, i still(??) can't delete this one directory, and it's behaving strangely. check it:

```
$ ls -l

total 3373

drwxr-xr-x 2 elassus users      48 Feb  8 22:25 foo

$ lsattr    

------------- ./foo

$ rmdir foo

rmdir: foo: Operation not permitted

$ rm -r foo

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

```

right now it's just annoying, but it does seem indicative of some problem. i have the extended attributes enabled in the kernel for this partition, and everything else seems to function normally now. it's just this.

if i could get help tying up these last loose ends, i'd really appreciate it. i also changed the post topic back to something less alarmist.

thanks,

EE

----------

## mv

 *ExecutorElassus wrote:*   

> i rebooted into a kernel that had the extended attributes flags on for reiserfs, and then ran 'reiserfsck --clean-attributes' on the partition.
> 
> ```
> $ ls -l
> 
> ...

 

Are you sure that the parent directory is writtable (and without any strange attributes)?

I think there is a severe bug with reiserfs for partitions which are (or have been converted from) reiserfs 3.5 in one of the new kernels (as I understood, the patch mentioned earlier in this thread is not really a fix, but only fixes the symptoms for 3.5 by forbidding all atributes). Let me explain what happened these days to me on several of my older reiserfs partitions (on different systems):

Suddenly, files (even newly created ones) appeared with strange attributes (like -I and many others). At the first attempt, reiserfsck --clean-attributes refused to work, because attributes are not supported for 3.5; so I mounted the partition once with -o conv (hence it is a reiserfs 3.6 from now on), and afterwards reiserfsck --clean-attributes was able to clear all attributes. However, new files still sometimes have strange attributes set.

My solution was to backup the data, create a new reiserfs 3.6 partion, and to restore the data - now the effect seems to be gone. My impression is that reiserfs simply does not handle converted (or unconverted) reiserfs 3.5 properly.

----------

## ExecutorElassus

not only have i changed the perms several times, and stripped the attributes, the attribs keep changing into something wacky.

ugh... now i'm making a bz2 of my ~, which is 14gb. i think i'll try a different fs for the drive, since reiser seems to be fussy. when i look at the partition that's been causing problems, i see that it is, in fact, a 3.6 reiserfs. so why is it bugging out? 

thanks,

EE

----------

## mv

 *ExecutorElassus wrote:*   

> not only have i changed the perms several times, and stripped the attributes, the attribs keep changing into something wacky.
> 
> ugh... now i'm making a bz2 of my ~, which is 14gb. i think i'll try a different fs for the drive, since reiser seems to be fussy. when i look at the partition that's been causing problems, i see that it is, in fact, a 3.6 reiserfs. so why is it bugging out?

 

And it was a 3.6 from the very beginning (not converted at some time)? Then my conjecture that it has something to do with 3.5 might be false.

In any case, it seems to be a bug related only to the latest kernel: I observed the problem beginning of this month (and it seems, some other people here, too: look for --clean-attributes), immediately after I have upgraded from hardened-sources-2.6.14-r4 to hardened-sources-2.6.14-r5 (probably at around the same time also a new gentoo-sources appeared - usually the gentoo-sources patches go immediately to hardened sources).

So I fear the bug was introduced by the gentoo kernel patches - perhaps no reason to blame reiserfs.

Added in edit:

If you have not erased your reiserfs yet, I suggest you write a bug report to the gentoo kernel team (for me, it is now hard to do this, because the bug currently does not appear anymore on my systems).

----------

