fsck deleting extended attributes

fsck deleting extended attributes

[Luke Kenneth Casson Leighton]

hi,

i was wondering if anyone had any ideas about how to deal with
fsck deleting extended attributes in order to repair the filesystem?

the issue is that if a system is switched off without shutdown and
the filesystem is damaged, such that some extended attributes are
deleted on an fsck, that's it - the file cannot be accessed!


i am setting up a system where the users will NOT be told what
the root password is, nor will they be given a user login
(they will be given an automatic KDE login), and there is
ABSOLUTELY no chance of either user support or admin support.

[someone might crack the root password, well, good luck to them].

in other words, if it breaks, and i haven't thought of a way to fix
it (by adding a "recovery" option) then it's Game Over.


what should i do?

a) get fsck.ext2 fixed?

b) forcibly run make -C /etc/selinux relabel from /etc/init.d/checkfs.sh

c) other.

i am sure that other people are / will come across this one, at some
point...

l.

-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fsck deleting extended attributes

[Russell Coker]

On Sun, 27 Jun 2004 08:03, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> the issue is that if a system is switched off without shutdown and
> the filesystem is damaged, such that some extended attributes are
> deleted on an fsck, that's it - the file cannot be accessed!

The fact that a file without a label is inaccessible to most programs is a bug 
not a feature.  You wouldn't want /etc/shadow to lose it's label and give 
away passwords...

No matter what you do there are situations in which a file system can be 
messed up beyond the ability of fsck to fix it.  By default there are many 
situations in which fsck will want to operate in manual mode (you have to 
edit something under /etc to have fsck run with -f to have it recover from 
most errors without intervention).

> i am setting up a system where the users will NOT be told what
> the root password is, nor will they be given a user login
> (they will be given an automatic KDE login), and there is
> ABSOLUTELY no chance of either user support or admin support.

How about mounting the root fs R/O so that it can't be messed up and then 
having /var and /home relabelled on some schedule (eg every 5th boot).

> a) get fsck.ext2 fixed?

I think it's already as good as it's going to get in this regard.

> b) forcibly run make -C /etc/selinux relabel from /etc/init.d/checkfs.sh

Yes, but not every boot.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fsck deleting extended attributes

[Luke Kenneth Casson Leighton]

On Sun, Jun 27, 2004 at 06:58:24PM +1000, Russell Coker wrote:
> On Sun, 27 Jun 2004 08:03, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > the issue is that if a system is switched off without shutdown and
> > the filesystem is damaged, such that some extended attributes are
> > deleted on an fsck, that's it - the file cannot be accessed!
> 
> The fact that a file without a label is inaccessible to most programs is a bug 
> not a feature.  You wouldn't want /etc/shadow to lose it's label and give 
> away passwords...
> 
> No matter what you do there are situations in which a file system can be 
> messed up beyond the ability of fsck to fix it.  By default there are many 
> situations in which fsck will want to operate in manual mode (you have to 
> edit something under /etc to have fsck run with -f to have it recover from 
> most errors without intervention).
> 
> > i am setting up a system where the users will NOT be told what
> > the root password is, nor will they be given a user login
> > (they will be given an automatic KDE login), and there is
> > ABSOLUTELY no chance of either user support or admin support.
> 
> How about mounting the root fs R/O so that it can't be messed up and then 
> having /var and /home relabelled on some schedule (eg every 5th boot).
> 
> > a) get fsck.ext2 fixed?
> 
> I think it's already as good as it's going to get in this regard.
> 
> > b) forcibly run make -C /etc/selinux relabel from /etc/init.d/checkfs.sh
> 
> Yes, but not every boot.
 
 i modified /etc/init.d/checkfs.sh as follows:

    echo "Checking all file systems..."
    fsck $spinner -R -A $fix $force
    if [ $? -gt 1 ]
            fsck $spinner -R -A $fix -y
            if [ $? -gt 1 ]
            then
              echo
              echo "fsck failed.  Please repair manually."
              echo
              echo "CONTROL-D will exit from this shell and continue system startup."
              echo
              # Start a single user shell on the console
              /sbin/sulogin $CONSOLE
            else

              # first file system check failed: second one forced
              # "yes" to repair so just in case we re-run the
              # relabelling of se/linux extended attributes...

              make -C /etc/selinux relabel
            fi
    then
    fi

 in other words, a [hopefully!] non-damaging fsck is done first,
 with detection that goes "eek", does a forced fsck and then
 runs relabel.

 i _hope_ that it's done under a context where the relabel can
 actually work!

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.