Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+information\s+leak\s+during\s+crash\s*$/: 22 ]

Total 22 documents matching your query.

1. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 10:11:07 +1100
Hello Jan, If you think you have found a security issue, it would be courteous to at least discuss this with the maintainers first. And since you are a frequent linux-xfs list poster too, it seems a
/archives/xfs/2005-11/msg00016.html (10,528 bytes)

2. Re: XFS information leak during crash (score: 1)
Author: Jan Kasprzak <kas@xxxxxxxxxx>
Date: Thu, 3 Nov 2005 00:36:29 +0100
Well, I think while it is a security issue, it is not serious enough to make it secret (it is not exploitable by anyone except those who are able to crash the machine). I am sorry for this one - I am
/archives/xfs/2005-11/msg00017.html (12,308 bytes)

3. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 10:49:56 +1100
No, thats not correct - XFS behaves as most filesystems do and will write over the top of existing data. XFS also rewrites files in-place. You will never get someone else's current data (that would b
/archives/xfs/2005-11/msg00018.html (9,562 bytes)

4. Re: XFS information leak during crash (score: 1)
Author: Jan Kasprzak <kas@xxxxxxxxxx>
Date: Thu, 3 Nov 2005 01:03:17 +0100
OK, thanks for the clarification. Of course. Yes, but an old data from previously deleted files (sendmail's temporary files, vim save files, etc) may contain a sensitive information. -Y. -- Jan "Yeny
/archives/xfs/2005-11/msg00019.html (9,662 bytes)

5. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 11:11:15 +1100
Indeed. But this is a generic issue affecting most filesystems; its not specific to XFS as your original mail claimed. cheers. -- Nathan
/archives/xfs/2005-11/msg00020.html (9,317 bytes)

6. Re: XFS information leak during crash (score: 1)
Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 3 Nov 2005 01:19:10 +0100 (CET)
either). Does XFS support a something like ext3's "data=ordered" mount No, it doesn't. BTW. Why does it sometimes overwrite files with zeros after crash and journal replay then? I thought that this w
/archives/xfs/2005-11/msg00021.html (9,065 bytes)

7. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 11:38:01 +1100
But I do intend to get _some_ work done today, so you can google for a more detailed answer there if you're interested. cheers. -- Nathan
/archives/xfs/2005-11/msg00022.html (9,705 bytes)

8. Re: XFS information leak during crash (score: 1)
Author: Glen Overby <overby@xxxxxxx>
Date: Wed, 2 Nov 2005 18:41:56 -0600 (CST)
It doesn't overwrite the file with zeros. You're getting an inode that has a non-zero size, but no data in the file. That is, a file that is a single hole. This happens because XFS logs metadata quic
/archives/xfs/2005-11/msg00023.html (9,455 bytes)

9. Re: XFS information leak during crash (score: 1)
Author: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 03 Nov 2005 12:45:49 +0000
Very true. You can use ext3 in data journalling mode if this is a concern but that guarantee has a performance cost
/archives/xfs/2005-11/msg00024.html (9,633 bytes)

10. Re: XFS information leak during crash (score: 1)
Author: "Theodore Ts'o" <tytso@xxxxxxx>
Date: Thu, 3 Nov 2005 12:05:27 -0500
The default ordered journalling mode solves this problem at a much lower cost. - Ted
/archives/xfs/2005-11/msg00026.html (10,795 bytes)

11. Re: XFS information leak during crash (score: 1)
Author: Jan Kasprzak <kas@xxxxxxxxxx>
Date: Wed, 9 Nov 2005 17:55:39 +0100
Sorry for the delay - I did the test on other filesystems as well: "random" (i.e. not rewritten) data after the hard reset were inside the files in the following filesystems: XFS ext3 data=writeback
/archives/xfs/2005-11/msg00053.html (10,601 bytes)

12. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 10:11:07 +1100
Hello Jan, If you think you have found a security issue, it would be courteous to at least discuss this with the maintainers first. And since you are a frequent linux-xfs list poster too, it seems a
/archives/xfs/2005-11/msg00171.html (10,528 bytes)

13. Re: XFS information leak during crash (score: 1)
Author: Jan Kasprzak <kas@xxxxxxxxxx>
Date: Thu, 3 Nov 2005 00:36:29 +0100
Well, I think while it is a security issue, it is not serious enough to make it secret (it is not exploitable by anyone except those who are able to crash the machine). I am sorry for this one - I am
/archives/xfs/2005-11/msg00172.html (12,308 bytes)

14. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 10:49:56 +1100
No, thats not correct - XFS behaves as most filesystems do and will write over the top of existing data. XFS also rewrites files in-place. You will never get someone else's current data (that would b
/archives/xfs/2005-11/msg00173.html (9,562 bytes)

15. Re: XFS information leak during crash (score: 1)
Author: Jan Kasprzak <kas@xxxxxxxxxx>
Date: Thu, 3 Nov 2005 01:03:17 +0100
OK, thanks for the clarification. Of course. Yes, but an old data from previously deleted files (sendmail's temporary files, vim save files, etc) may contain a sensitive information. -Y. -- Jan "Yeny
/archives/xfs/2005-11/msg00174.html (9,662 bytes)

16. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 11:11:15 +1100
Indeed. But this is a generic issue affecting most filesystems; its not specific to XFS as your original mail claimed. cheers. -- Nathan
/archives/xfs/2005-11/msg00175.html (9,317 bytes)

17. Re: XFS information leak during crash (score: 1)
Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 3 Nov 2005 01:19:10 +0100 (CET)
either). Does XFS support a something like ext3's "data=ordered" mount No, it doesn't. BTW. Why does it sometimes overwrite files with zeros after crash and journal replay then? I thought that this w
/archives/xfs/2005-11/msg00176.html (9,065 bytes)

18. Re: XFS information leak during crash (score: 1)
Author: Nathan Scott <nathans@xxxxxxx>
Date: Thu, 3 Nov 2005 11:38:01 +1100
But I do intend to get _some_ work done today, so you can google for a more detailed answer there if you're interested. cheers. -- Nathan
/archives/xfs/2005-11/msg00177.html (9,705 bytes)

19. Re: XFS information leak during crash (score: 1)
Author: Glen Overby <overby@xxxxxxx>
Date: Wed, 2 Nov 2005 18:41:56 -0600 (CST)
It doesn't overwrite the file with zeros. You're getting an inode that has a non-zero size, but no data in the file. That is, a file that is a single hole. This happens because XFS logs metadata quic
/archives/xfs/2005-11/msg00178.html (9,455 bytes)

20. Re: XFS information leak during crash (score: 1)
Author: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 03 Nov 2005 12:45:49 +0000
Very true. You can use ext3 in data journalling mode if this is a concern but that guarantee has a performance cost
/archives/xfs/2005-11/msg00179.html (9,633 bytes)


This search system is powered by Namazu