- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: How do I re-attach an i-node
Operating System - HP-UX
1752720
Members
5579
Online
108789
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2004 10:27 AM
07-23-2004 10:27 AM
Solution
Hello Tim, hello everybody
thanks for making a number of additional, good points. I will try and answer them while at the same time improve my previous explanations.
In summary, if you rm a file that is being held open by a running process, you only lose it's "reference by name", because the directory entry is being removed. The computer prefers to know files by inode number, so the OS is still fine and the process can still read from or write to the file. The icat tool from TCT/TSK is designed to read such a file by just specifying the inode number and the file system's device file, but of course only for supported file systems. In terms of "evil software", I have not checked myself so the following is a guess: The attacker may possess low-level tools to do either 1) or 2) of what Tim has listed, but most likely he does 3) e.g. after a signal was sent to the sniffer software it could copy the data into another file... Another interesting thing in this context is that on HP-UX you cannot rm the executable of a running process. In other UNIXes you can, thus attackers sometimes do this to "hide" their malware process from disk scans by file integrity checking software like tripwire.
Tim, if you now want to destroy the data, that is quite a different story. Even if you rm a file which no process has currently open, the data is often not destroyed, contrary to what you wrote in decribing you 2nd scenario. This of course depends on the file system, but what I've seen so far with FFS/UFS/HFS for Sun/HP/*BSD, ext2/3 and JFS for Linux, (and in some sense in FAT and NTFS too) is the following:
When a file gets rm'ed, first its filename is being removed from the directory where it resided in. For multiple reasons, already this step is often times not a true erasure, but the directory entry is just marked invisible. For this reason, the fls tool of TSK is able to list names of deleted files and sometimes even the inode numbers of those deleted files. HP-UX's HFS is the exception here, it zeroizes both the name string and the inode number. (in the past, a poor man's version of fls was to just run 'strings' on a directory, but nowadays, many UNIXes disallow this).
The second step in file deletion deals with the inode. There the refcount is set to zero and the inode is marked as free in the inode allocation table. Then the disk block pointers are examined and the disk blocks are marked as free *in the disk block allocation table*, i.e. the disk blocks themselves are not zeroized, so your data remains on disk and may very well "survive" for years to come, depending on the usage pattern of the disk. HP-UX's HFS, Solaris and *BSD UFS do then zeroize the disk block pointers, which makes it harder to "undelete" the file, because you don't know which "free" disk block belonged to which former file. But the data is still there and Linux even keeps the block pointers, so there "icat" can be used to easily undelete a rm'ed file, assuming that its disk blocks are not already in use by another file. For the other UNIXes TCT offers the lazarus tool, which tries to classify disk blocks which are "officially" free, and because UFS/FFS/FFS try to allocate files contiguously on disk, success rates at least for small file sizes are not too bad.
So for really "destroying' a file in UNIX you have to overwrite it with e.g. all zeros (or multiple overwrites with alternating bit pattern, depending on you level of paranoia :-) before actually deleting it. There are "secure deletion" utilities available which perform this task, although off my head I don't know a product name for HP-UX. Such a tool may either choose to ignore file system specifics and open the file in write mode, or it may query the system via an ioctl for the actual sectors in use by the file and directly deal with those. While the first approach is easy to implement, there is the risk that the file system decides to reallocate the file to another set of disk blocks when it "sees" the write requests intended to overwrite the existing file.
Tim, your problem with this is that these tools - as far as I know - only work with files that still exist (although it should not be too hard for the implementor of such a tool to accept an inode number instead of a file name...). So in your case you would again have to re-attach using fsdb.
Clay, on a second thought, do you really think re-attaching would be that "dangerous". I mean, barring typos while using fsdb technically I think all you would have to do is create another directory entry that points to the inode number in question. Regarding updating the refcount, in HP-UX's HFS that would not even be necessary, because that is still kept at 1 even though the file has been "officially" deleted (don't know about vxfs of course).
Josh, sorry but no HP-UX/vxfs specific news from my side. I'm also not aware of a commercial offering for HP-UX. About a year ago I saw an ad for an undelete tool for AIX' JFS and JFS2. I myself did an extension of TCT/TSK to JFS for Linux, mostly to learn/study journaling file systems. This was considerably easier than vxfs/onlinejfs because the file system has been "donated" to Linux by IBM and excellent documentation about the layout of data and meta-data is available. Thus the internals in that case were known and it was not too difficult to implement, as you were stating in your post. Probably a week of coding and two weeks of testing/verification. (My JFS for Linux modul for TSK is not yet published, I'm waiting for TSK 2.0 plus I have to tie up a few loose ends here and there...)
I know I've left out some details but regretfully I'm running out of time...
Best regards,
Knut
PS: We may ask the forum admin to award some extra points for what probably is the longest running thread ever (or at least the thread with the longest intermittent breaks :-)
thanks for making a number of additional, good points. I will try and answer them while at the same time improve my previous explanations.
In summary, if you rm a file that is being held open by a running process, you only lose it's "reference by name", because the directory entry is being removed. The computer prefers to know files by inode number, so the OS is still fine and the process can still read from or write to the file. The icat tool from TCT/TSK is designed to read such a file by just specifying the inode number and the file system's device file, but of course only for supported file systems. In terms of "evil software", I have not checked myself so the following is a guess: The attacker may possess low-level tools to do either 1) or 2) of what Tim has listed, but most likely he does 3) e.g. after a signal was sent to the sniffer software it could copy the data into another file... Another interesting thing in this context is that on HP-UX you cannot rm the executable of a running process. In other UNIXes you can, thus attackers sometimes do this to "hide" their malware process from disk scans by file integrity checking software like tripwire.
Tim, if you now want to destroy the data, that is quite a different story. Even if you rm a file which no process has currently open, the data is often not destroyed, contrary to what you wrote in decribing you 2nd scenario. This of course depends on the file system, but what I've seen so far with FFS/UFS/HFS for Sun/HP/*BSD, ext2/3 and JFS for Linux, (and in some sense in FAT and NTFS too) is the following:
When a file gets rm'ed, first its filename is being removed from the directory where it resided in. For multiple reasons, already this step is often times not a true erasure, but the directory entry is just marked invisible. For this reason, the fls tool of TSK is able to list names of deleted files and sometimes even the inode numbers of those deleted files. HP-UX's HFS is the exception here, it zeroizes both the name string and the inode number. (in the past, a poor man's version of fls was to just run 'strings' on a directory, but nowadays, many UNIXes disallow this).
The second step in file deletion deals with the inode. There the refcount is set to zero and the inode is marked as free in the inode allocation table. Then the disk block pointers are examined and the disk blocks are marked as free *in the disk block allocation table*, i.e. the disk blocks themselves are not zeroized, so your data remains on disk and may very well "survive" for years to come, depending on the usage pattern of the disk. HP-UX's HFS, Solaris and *BSD UFS do then zeroize the disk block pointers, which makes it harder to "undelete" the file, because you don't know which "free" disk block belonged to which former file. But the data is still there and Linux even keeps the block pointers, so there "icat" can be used to easily undelete a rm'ed file, assuming that its disk blocks are not already in use by another file. For the other UNIXes TCT offers the lazarus tool, which tries to classify disk blocks which are "officially" free, and because UFS/FFS/FFS try to allocate files contiguously on disk, success rates at least for small file sizes are not too bad.
So for really "destroying' a file in UNIX you have to overwrite it with e.g. all zeros (or multiple overwrites with alternating bit pattern, depending on you level of paranoia :-) before actually deleting it. There are "secure deletion" utilities available which perform this task, although off my head I don't know a product name for HP-UX. Such a tool may either choose to ignore file system specifics and open the file in write mode, or it may query the system via an ioctl for the actual sectors in use by the file and directly deal with those. While the first approach is easy to implement, there is the risk that the file system decides to reallocate the file to another set of disk blocks when it "sees" the write requests intended to overwrite the existing file.
Tim, your problem with this is that these tools - as far as I know - only work with files that still exist (although it should not be too hard for the implementor of such a tool to accept an inode number instead of a file name...). So in your case you would again have to re-attach using fsdb.
Clay, on a second thought, do you really think re-attaching would be that "dangerous". I mean, barring typos while using fsdb technically I think all you would have to do is create another directory entry that points to the inode number in question. Regarding updating the refcount, in HP-UX's HFS that would not even be necessary, because that is still kept at 1 even though the file has been "officially" deleted (don't know about vxfs of course).
Josh, sorry but no HP-UX/vxfs specific news from my side. I'm also not aware of a commercial offering for HP-UX. About a year ago I saw an ad for an undelete tool for AIX' JFS and JFS2. I myself did an extension of TCT/TSK to JFS for Linux, mostly to learn/study journaling file systems. This was considerably easier than vxfs/onlinejfs because the file system has been "donated" to Linux by IBM and excellent documentation about the layout of data and meta-data is available. Thus the internals in that case were known and it was not too difficult to implement, as you were stating in your post. Probably a week of coding and two weeks of testing/verification. (My JFS for Linux modul for TSK is not yet published, I'm waiting for TSK 2.0 plus I have to tie up a few loose ends here and there...)
I know I've left out some details but regretfully I'm running out of time...
Best regards,
Knut
PS: We may ask the forum admin to award some extra points for what probably is the longest running thread ever (or at least the thread with the longest intermittent breaks :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-30-2004 06:45 AM
07-30-2004 06:45 AM
Re: How do I re-attach an i-node
Knut
May thanks for the reply. I've learnt quite a few things from it. I'm giving you 10 points not so much because you answered my question, but because you told me why the answer (what I wanted from it any way) is no-can-do...
Cheers
Tim
May thanks for the reply. I've learnt quite a few things from it. I'm giving you 10 points not so much because you answered my question, but because you told me why the answer (what I wanted from it any way) is no-can-do...
Cheers
Tim
-
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP