Re: [Dump-users] restore -C EA (SELinux) problem

[Tony N. <ton...@ge...>]

At 10:32 AM +0200 4/24/06, Stelian Pop wrote:
>Le dimanche 23 avril 2006 =FD 22:18 -0400, Tony Nelson a =C8crit :
>> At 2:20 PM -0400 4/23/06, Tony Nelson wrote:
>> >I'm trying to learn how to use dump and restore (to/from DVD+/-R), and I=
've
>> >gotten it working to the point where the file data seems to be OK but th=
e
>> >SELinux Extended Attributes are not.  I used the commands (as root, with=
 my
>> >/ being LogVol02):
>> >
>> >    # mount -r /dev/VolGroup00/LogVol00 /mnt/lv00
>> >    # dump -0 -L xxx -B 4590208 -f /tmp/dumpdvd /dev/VolGroup00/LogVol00
>> >        [cdrecord used once per tape, from another terminal]
>> >        # cdrecord -v -sao dev=3Ddvd -data /tmp/dumpdvd
>> >    # restore -C -f /dev/dvd
>> >
>> >OK, some of that is superstition, but it works except for one of these
>> >messages for each file, and no other errors (according to grep -v):
>> >
>> >    ./path/to/file: EA foo_x:object_r:bar_y value changed
>>  ...
>>
>> OK, now I understand that these errors are due to a change in SELinux in
>> Fedora Core 5, where the 4th component (MLS) of the Security Context has
>> been enabled.  When dump did the backup of the volume made under FC3, it
>> only dumped the 3 components that were in current use.
>
>dump should backup *all* the EA which are set on the original inode. The
>syscall which is used to retrieve the EA value doesn't know anything
>about a 3 or 4 component value. It just retrieves the full value in a
>buffer.

Dump must back up all the EA, as it doesn't seem to be looking inside EAs
when it dumps them.  The problem is that on previous versions of SELinux,
the 4th (MLS) field was not used, and was therefor not set, so there is no
value to restore.


>So I don't believe this is the cause, or at least not directly.

I have only looked at the dump and restore source for a bit, but I believe
that dump dumps all of the EA and restore views files through the
filesystem calls, which invoke SELinux code that "improve" the results if
the MLS data is not present on disk.  Restore -C then compares the string
returned by the filesystem call with the string on disk and is unhappy.
Therefore the cause of the difference is the change in SELinux.


>Before going further, let's just verify exactly what got changed. You
>can retrieve the value of EA's using the getfattr command, like in:
>	getfattr -d -m . /tmp/foo
>
>(-d is for dumping all the EA, -m is the pattern search for the EAs,
>here we want to dump all the EAs).

I had already used getxattr() via Python.  A file on the mount made under
=46C3 showed the MLS field, but that field was not in the dump, as shown by
restore.


>Try restoring your backup (not just verifying it), and run getfattr on
>both the original and the extracted file. What is the result ?

I'm sorry, but I'm not going to wipe my FC3 volume to do this.  Given that
I'm not entirely sure that the dump is good, wiping out the original would
be imprudent.
____________________________________________________________________
TonyN.:'                       <mailto:ton...@ge...>
      '                              <http://www.georgeanelson.com/>