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

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)

Current List: 1 - 20
Page: [1] [2]