Skip to contentSkip to conversation

The stickybit!!

DISCUSSION Jagadeesh Bhaskar P 3 participants 5 messages Dec 17, 2004 – Dec 18, 2004

lore
Share & tools
lore
#0 lore raw

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??

Signature · 3 lines
With regards,

Jagadeesh Bhaskar P
#1 lore raw

On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <[email protected]> wrote in message <1103265276.6880.8.camel@myLinux>:

Quoted 3 lines

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.

Quoted 2 lines

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

Signature · 4 lines
Jan-Benedict Glaw       [email protected]    . +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));
#2 lore raw
Quoted 10 lines · Jan-Benedict Glaw

On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <[email protected]> wrote in message <1103265276.6880.8.camel@myLinux>:

Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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!!

Quoted 1 line

MfG, JBG

Signature · 3 lines
With regards,

Jagadeesh Bhaskar P
#3 lore raw

On Fri, 2004-12-17 16:08:20 +0530, Jagadeesh Bhaskar P <[email protected]> wrote in message <1103279900.3797.13.camel@myLinux>:

Quoted 7 lines · Jan-Benedict Glaw
Quoted 6 lines

On Fri, 2004-12-17 12:04:36 +0530, Jagadeesh Bhaskar P <[email protected]> wrote in message <1103265276.6880.8.camel@myLinux>:

Quoted 2 lines

Is there a way to findout the data if residing in swap area after the
process is terminated, using a C program??

Quoted 6 lines
Quoted 4 lines

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

Signature · 4 lines
Jan-Benedict Glaw       [email protected]    . +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));
#4 lore raw
In reply to Jagadeesh Bhaskar P
Quoted 5 lines · Jagadeesh Bhaskar P

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.

Signature · 1 line
Glynn Clements <[email protected]>