All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Sergey Vlasov <vsu@altlinux.ru>, Jeff Mahoney <jeffm@suse.com>
Cc: Bernd Schubert <bernd-schubert@gmx.de>,
	Chris Wright <chrisw@sous-sol.org>,
	John M Flinchbaugh <john@hjsoft.com>,
	reiserfs-list@namesys.com, Sam Vilain <sam@vilain.net>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.15 Bug? New security model?
Date: Sun, 12 Feb 2006 21:47:28 -0800	[thread overview]
Message-ID: <43F01D70.70600@namesys.com> (raw)
In-Reply-To: <20060212005541.107f7011.vsu@altlinux.ru>

This is an xattr bug, and I'll let jeff answer it.

Hans

Sergey Vlasov wrote:

>On Wed, 8 Feb 2006 14:11:24 -0800 Chris Wright wrote:
>
>  
>
>>* Bernd Schubert (bernd-schubert@gmx.de) wrote:
>>    
>>
>>>Er, you mean /proc/fs/reiserfs/{partition}/on-disk-super?
>>>      
>>>
>>Yup.
>>
>>    
>>
>>>bernd@bathl ~>grep attrs_cleared /proc/fs/reiserfs/hda6/on-disk-super
>>>flags:  1[attrs_cleared]
>>>      
>>>
>>>>2) does mount -o attrs ... make a difference?
>>>>        
>>>>
>>>Yes, 2.6.13 now makes the same trouble. No difference with 2.6.15.3. 
>>>I played with mount -o noattrs, this makes no difference with 2.6.13, but has 
>>>some effects to 2.6.15.3. Creating files in /var/run is possible again, 
>>>lsattr gives "lsattr: Inappropriate ioctl for device While reading flags 
>>>on /var/run", but deleting files in /var/run is still impossible (still 
>>>rather bad for the init-scripts).
>>>      
>>>
>
>Is the filesystem in question old - could it be created initially in the
>reiserfs v3.5 format (used with 2.2.x kernels) and later converted to
>v3.6 (by mounting with the "conv" option)?
>
>  
>
>>Yes, that's what I thought.  There's still some backward logic in there.
>>noattrs vs. attrs triggers whether the code path that's patched in
>>2.6.15.3 is taken.  I'll dig a bit more, but hopefully the reiserfs folks 
>>can fix this for us.
>>    
>>
>
>Here is a simple test case which reproduces the problem with a
>filesystem converted from v3.5:
>
># dd if=/dev/zero of=tmp.img bs=1M count=100
># mkreiserfs --format 3.5 -f tmp.img
># mount -t reiserfs -o loop,conv tmp.img /mnt/disk/
># umount /mnt/disk/
># reiserfsck --clean-attributes tmp.img
># mount -t reiserfs -o loop tmp.img /mnt/disk/
>
>At this point, I get obviously wrong attributes on /mnt/disk:
>
># lsattr -d /mnt/disk/
>-----a--c---- /mnt/disk/
>
>BTW, this breaks even with kernels earlier than 2.6.15.2, if you also
>add the "attrs" options to the last mount command.
>
>Apparently the reiserfs attrs code has been broken for such converted
>filesystems for some time, but it could be enabled only with the "attrs"
>option, so people were not hitting this.  However, the following patch:
>
>http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2949ccf9379678df66ecf2ca70ed4656159eacdd
>
>changed the logic to enable the "attrs" option on all filesystems which
>have the reiserfs_attrs_cleared flag.  But that patch was broken - it
>did not really set the option properly, so the attrs-related breakage
>did not became visible until yet another patch:
>
>http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d35c602870ece3166cff3d25fbc687a7f707acf3
>
>which later made into 2.6.15.2, and caused problems for some people.
>
>I have noticed that fs/reiserfs/inode.c:init_inode() does not initialize
>REISERFS_I(inode)->i_attrs and inode->i_flags (as done by
>sd_attrs_to_i_attrs()) in the branch for v1 stat data; maybe this causes
>the problem?
>  
>

  parent reply	other threads:[~2006-02-13  5:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-08  1:12 2.6.15 Bug? New security model? Bernd Schubert
2006-02-08  1:31 ` Sam Vilain
2006-02-08  5:37   ` John M Flinchbaugh
2006-02-08 12:14     ` Bernd Schubert
2006-02-08 20:50       ` Chris Wright
2006-02-08 21:46         ` Bernd Schubert
2006-02-08 22:11           ` Chris Wright
2006-02-11 21:55             ` Sergey Vlasov
2006-02-11 23:50               ` Bernd Schubert
2006-02-12 18:44                 ` Sergey Vlasov
2006-02-12 17:57               ` Jeff Mahoney
2006-02-12 19:21                 ` Sergey Vlasov
2006-02-12 23:03                   ` Bernd Schubert
2006-02-13 17:52                     ` Sergey Vlasov
2006-02-12 23:10                 ` Bernd Schubert
2006-02-13  5:47               ` Hans Reiser [this message]
2006-02-13 15:24                 ` Jeff Mahoney
2006-02-13 16:39                   ` Hans Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43F01D70.70600@namesys.com \
    --to=reiser@namesys.com \
    --cc=bernd-schubert@gmx.de \
    --cc=chrisw@sous-sol.org \
    --cc=jeffm@suse.com \
    --cc=john@hjsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-list@namesys.com \
    --cc=sam@vilain.net \
    --cc=vsu@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.