* The stickybit!! @ 2004-12-17 6:34 Jagadeesh Bhaskar P 2004-12-17 9:34 ` Jan-Benedict Glaw 2004-12-18 0:25 ` Glynn Clements 0 siblings, 2 replies; 5+ messages in thread From: Jagadeesh Bhaskar P @ 2004-12-17 6:34 UTC (permalink / raw) To: Linux C Programming Hi, Though it is known that stickybit is obsolete, im just curious to see the effect of setting a sticky bit on an executable file. Is there a way to findout the data if residing in swap area after the process is terminated, using a C program?? -- With regards, Jagadeesh Bhaskar P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The stickybit!! 2004-12-17 6:34 The stickybit!! Jagadeesh Bhaskar P @ 2004-12-17 9:34 ` Jan-Benedict Glaw 2004-12-17 10:38 ` Jagadeesh Bhaskar P 2004-12-18 0:25 ` Glynn Clements 1 sibling, 1 reply; 5+ messages in thread From: Jan-Benedict Glaw @ 2004-12-17 9:34 UTC (permalink / raw) To: Linux C Programming [-- Attachment #1: Type: text/plain, Size: 1199 bytes --] On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <jbhaskar@hclinsys.com> wrote in message <1103265276.6880.8.camel@myLinux>: > Hi, > Though it is known that stickybit is obsolete, im just curious to see > the effect of setting a sticky bit on an executable file. It isn't obsolete. It's a rarely used feature that's actually quite important. Most of the time, you can try to work around it, but the sticky bit will most probably just stay as it is. > Is there a way to findout the data if residing in swap area after the > process is terminated, using a C program?? Not (easily), at last. You can try to open the swap area(s) with O_DIRECT and prepare a copy of it. However, you don't know which pages were owned by the terminated process formerly so you only can step through all the bytes and hope to find something useful... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The stickybit!! 2004-12-17 9:34 ` Jan-Benedict Glaw @ 2004-12-17 10:38 ` Jagadeesh Bhaskar P 2004-12-17 15:20 ` Jan-Benedict Glaw 0 siblings, 1 reply; 5+ messages in thread From: Jagadeesh Bhaskar P @ 2004-12-17 10:38 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: Linux C Programming On Fri, 2004-12-17 at 15:04, Jan-Benedict Glaw wrote: > On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <jbhaskar@hclinsys.com> > wrote in message <1103265276.6880.8.camel@myLinux>: > > Hi, > > Though it is known that stickybit is obsolete, im just curious to see > > the effect of setting a sticky bit on an executable file. > > It isn't obsolete. It's a rarely used feature that's actually quite > important. Most of the time, you can try to work around it, but the > sticky bit will most probably just stay as it is. > > > Is there a way to findout the data if residing in swap area after the > > process is terminated, using a C program?? > > Not (easily), at last. You can try to open the swap area(s) with > O_DIRECT and prepare a copy of it. However, you don't know which pages > were owned by the terminated process formerly so you only can step > through all the bytes and hope to find something useful... Im not able to get that part completely. Can a bit more explanation be given!! > MfG, JBG -- With regards, Jagadeesh Bhaskar P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The stickybit!! 2004-12-17 10:38 ` Jagadeesh Bhaskar P @ 2004-12-17 15:20 ` Jan-Benedict Glaw 0 siblings, 0 replies; 5+ messages in thread From: Jan-Benedict Glaw @ 2004-12-17 15:20 UTC (permalink / raw) To: Linux C Programming [-- Attachment #1: Type: text/plain, Size: 3081 bytes --] On Fri, 2004-12-17 16:08:20 +0530, Jagadeesh Bhaskar P <jbhaskar@hclinsys.com> wrote in message <1103279900.3797.13.camel@myLinux>: > On Fri, 2004-12-17 at 15:04, Jan-Benedict Glaw wrote: > > On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <jbhaskar@hclinsys.com> > > wrote in message <1103265276.6880.8.camel@myLinux>: > > > Is there a way to findout the data if residing in swap area after the > > > process is terminated, using a C program?? > > > > Not (easily), at last. You can try to open the swap area(s) with > > O_DIRECT and prepare a copy of it. However, you don't know which pages > > were owned by the terminated process formerly so you only can step > > through all the bytes and hope to find something useful... > Im not able to get that part completely. Can a bit more explanation be > given!! Well, facts about swapping (or paging, what Linux actually does): - After detecting memory shortage, some chunk of RAM is put onto some stable medium (most probably partitions of HDDs or swap files). - You don't know IF memory of some application actually gets paged out. Though, you can try to force that by allocating and using lots of memory, but you cannot force a specific page to be swapped out. - If a page was swapped out, you don't know (a) which memory region of the process it belonged to and (b) to which area of the swap space the given page was written to. If you attempt to get access to the swap area(s), you want your application to *not* swap. If you're root (certainly you need to be root: only a moron would allow ordinary users to directly access block device's partitions...), you may lock all your address space to be non-pageable. Additionally, you want that no other apps get paged out: this would possibly overwrite important data you want to recover. O_DIRECT is a method to tell the kernel you know better about what needs to be cached -- and what not. Because you're reading and writing a whole lot of data (typically several hundreths of megabytes), you don't want to pressure that into RAM. Just tell the kernel the data is never ever accessed again, so there's no point in wasting RAM for it (which could make other applications to swap more). The same thing counts for your private output file, of course. But even then, you've got a large file with a lot of binary garbage. I guess it'll be fun (TM) to recover useful data from it. Actually, I've played with that some time ago by searching for previously issued input (while forcing a near-out-of-memory situation). It works, but honestly, I hadn't been able to actually *find* the information in question without priorly knowing what to search for... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: The stickybit!! 2004-12-17 6:34 The stickybit!! Jagadeesh Bhaskar P 2004-12-17 9:34 ` Jan-Benedict Glaw @ 2004-12-18 0:25 ` Glynn Clements 1 sibling, 0 replies; 5+ messages in thread From: Glynn Clements @ 2004-12-18 0:25 UTC (permalink / raw) To: Jagadeesh Bhaskar P; +Cc: Linux C Programming Jagadeesh Bhaskar P wrote: > Though it is known that stickybit is obsolete, im just curious to see > the effect of setting a sticky bit on an executable file. > > Is there a way to findout the data if residing in swap area after the > process is terminated, using a C program?? Read-only sections (e.g. text, rodata) of binaries (executables or libraries) will never end up in the swap file. Either they reside in RAM or they don't; if they don't, they will be read in from the binary as required. The swap file is only used for storing mutable data (e.g. data or bss sections of binaries, memory allocated by brk() or anonymous mmap(), or writeable mmap()ed files using MAP_PRIVATE). Immutable data is already stored in the mapped file, so there's no point in copying it to swap. As for the question which you presumably meant to ask, i.e. how to determine if a particular page of a file is currently stored in physical RAM, I don't have an answer. Obviously, the kernel has this information, so you could always dig it out of /dev/kmem or /proc/kcore or similar. I don't know whether there's a better interface. -- Glynn Clements <glynn@gclements.plus.com> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-12-18 0:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-17 6:34 The stickybit!! Jagadeesh Bhaskar P 2004-12-17 9:34 ` Jan-Benedict Glaw 2004-12-17 10:38 ` Jagadeesh Bhaskar P 2004-12-17 15:20 ` Jan-Benedict Glaw 2004-12-18 0:25 ` Glynn Clements
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.