From: John M Flinchbaugh <john@hjsoft.com>
To: Sam Vilain <sam@vilain.net>
Cc: Bernd Schubert <bernd-schubert@gmx.de>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.15 Bug? New security model?
Date: Wed, 8 Feb 2006 00:37:32 -0500 [thread overview]
Message-ID: <20060208053732.GA13560@butterfly.hjsoft.com> (raw)
In-Reply-To: <43E94A02.2080205@vilain.net>
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
On Wed, Feb 08, 2006 at 02:31:46PM +1300, Sam Vilain wrote:
> Bernd Schubert wrote:
> >With 2.6.15:
> >bathl:~# touch /var/run/test
> >touch: cannot touch `/var/run/test': Permission denied
> >With 2.6.13:
> >bathl:~# touch /var/run/test
> >(No error message)
>
> Some ideas; ACLs, SELinux, Attributes, Capabilities.
lsattr -d /var/run && lsattr /var/run
I saw very similar things going from 2.6.15.1 to 2.6.15.2. 2.6.15.2's
changelog advertises a fix to reenable extended attributes on reiserfs.
On one machine this is fine, and lsattr shows no attributes enabled
(----------), but on another machine, I ended up with all sorts of crazy
attributes set seemingly randomly -- compression, experimental flags,
immutable, append-only, all over the map.
I tried clearing them (chattr -R = /var ...etc), but I still found a
file here and there which refused to be removed, even though lsattr
showed no flags for it. After a restart or 2, I saw some attributes
revert back and I started having trouble removing files from /var/run
and other places again.
I ended up reverting back to 2.6.15.1 until I have a chance to
investigate further and try to come up with something reportable. In
2.6.15.1, attributes didn't work at all, giving an ioctl error, though
the same kernel options were used. I suspect this is the fix to which
the Changelog is referring.
I must wonder if I'm suffering from some sort of fs corruption which
only manifests itself in the attribute settings, and which a reisefsck
doesn't recognize or correct. I could be tempted to recreate the
filesystems from scratch to see if they still have issues.
--
John M Flinchbaugh
john@hjsoft.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-02-08 5:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 1:12 Bernd Schubert
2006-02-08 1:31 ` Sam Vilain
2006-02-08 5:37 ` John M Flinchbaugh [this message]
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
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=20060208053732.GA13560@butterfly.hjsoft.com \
--to=john@hjsoft.com \
--cc=bernd-schubert@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@vilain.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome