Menu
▾
▴
dump-users
|
From: Tony N. <ton...@ge...> - 2006-04-23 18:24:35
|
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 the
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=dvd -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
What am I doing wrong? I've tried restore -C with setenforce 0, and with
mouting read-write.
Is there a way to see what the dump'ed file info and EA's are?
____________________________________________________________________
TonyN.:' <mailto:ton...@ge...>
' <http://www.georgeanelson.com/>
|
|
From: Tony N. <ton...@ge...> - 2006-04-24 02:18:40
|
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 the
>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=dvd -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. When restore tried
to compare the backup with the volume, it got "invented" MLS components, so
the security contexts did differ.
I expect that restore needs to cope with this somehow. Possibly SELinux
needs some work as well -- I'll ask for help on the fedora-selinux-list.
____________________________________________________________________
TonyN.:' <mailto:ton...@ge...>
' <http://www.georgeanelson.com/>
|
|
From: Stelian P. <st...@po...> - 2006-04-24 08:32:56
|
Le dimanche 23 avril 2006 =E0 22:18 -0400, Tony Nelson a =E9crit : > 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 = the > >SELinux Extended Attributes are not. I used the commands (as root, wi= th my > >/ being LogVol02): > > > > # mount -r /dev/VolGroup00/LogVol00 /mnt/lv00 > > # dump -0 -L xxx -B 4590208 -f /tmp/dumpdvd /dev/VolGroup00/LogVol= 00 > > [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 > ... >=20 > OK, now I understand that these errors are due to a change in SELinux i= n > Fedora Core 5, where the 4th component (MLS) of the Security Context ha= s > been enabled. When dump did the backup of the volume made under FC3, i= t > 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. So I don't believe this is the cause, or at least not directly. 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). Try restoring your backup (not just verifying it), and run getfattr on both the original and the extracted file. What is the result ? Stelian. --=20 Stelian Pop <st...@po...> |
|
From: Tony N. <ton...@ge...> - 2006-04-24 18:34:38
|
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/>
|
|
From: Stelian P. <st...@po...> - 2006-04-24 19:01:18
|
Le lundi 24 avril 2006 =E0 14:34 -0400, Tony Nelson a =E9crit : > I have only looked at the dump and restore source for a bit, but I beli= eve > 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.=20 Ah ok, seems plausible indeed. > >Try restoring your backup (not just verifying it), and run getfattr on > >both the original and the extracted file. What is the result ? >=20 > I'm sorry, but I'm not going to wipe my FC3 volume to do this. Given t= hat > I'm not entirely sure that the dump is good, wiping out the original wo= uld > be imprudent. Oh no, I didn't meant to wipe your existing volume, just extract the dump (or a part of it) into another, temporary directory... But if you're correct it won't show any difference at all since once the files are created by restore, with the 'old' EA, further getxattrs will return the 'improved' EA... Stelian. --=20 Stelian Pop <st...@po...> |
|
From: Tony N. <ton...@ge...> - 2006-04-25 02:29:35
|
At 9:01 PM +0200 4/24/06, Stelian Pop wrote: >Le lundi 24 avril 2006 =FD 14:34 -0400, Tony Nelson a =C8crit : > >> I have only looked at the dump and restore source for a bit, but I believ= e >> 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.=20 > >Ah ok, seems plausible indeed. > >> >Try restoring your backup (not just verifying it), and run getfattr on >> >both the original and the extracted file. What is the result ? >>=20 >> I'm sorry, but I'm not going to wipe my FC3 volume to do this. Given tha= t >> I'm not entirely sure that the dump is good, wiping out the original woul= d >> be imprudent. > >Oh no, I didn't meant to wipe your existing volume, just extract the >dump (or a part of it) into another, temporary directory... > >But if you're correct it won't show any difference at all since once the >files are created by restore, with the 'old' EA, further getxattrs will >return the 'improved' EA... I've filed bugs against restore (so the maintainers know about the issue) and against Fedora Core 5 SELinux: [ dump-Bugs-1475895 ] FC5 SELinux causes miscompares for restore -C https://sourceforge.net/tracker/?func=3Ddetail&atid=3D101306&aid=3D1475895&g= roup_id=3D1306 [Bug 189845] New: FC5 SELinux causes miscompares for restore -C https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D189845 ____________________________________________________________________ TonyN.:' <mailto:ton...@ge...> ' <http://www.georgeanelson.com/> |
|
From: Stelian P. <st...@po...> - 2006-04-25 08:47:56
|
Le lundi 24 avril 2006 =E0 22:26 -0400, Tony Nelson a =E9crit : > I've filed bugs against restore (so the maintainers know about the issu= e) > and against Fedora Core 5 SELinux: >=20 > [ dump-Bugs-1475895 ] FC5 SELinux causes miscompares for restore -C > https://sourceforge.net/tracker/?func=3Ddetail&atid=3D101306&aid=3D1475= 895&group_id=3D1306 >=20 > [Bug 189845] New: FC5 SELinux causes miscompares for restore -C > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D189845 Thanks for doing this. I tend to think this is more a design issue in SELinux itself (like in 'how a SELinux labeled volume must be backuped ?') than a bug in restore. As I said in my previous post, the solution might be to never backup the security related EAs, and just tell the user to relabel the partition after the restore. I guess I'll just wait and see what the SELinux guys think about this. Stelian. --=20 Stelian Pop <st...@po...> |
Thanks for helping keep SourceForge clean.
X