Re: memory managment and (its) protection under Linux

On 8/20/24 2:27 PM, The Natural Philosopher wrote:

On 20/08/2024 14:09, MarioCCCP wrote:

>
partially OT : programming task
Scenario : Debian Bookworm, XFCE4
Very often GUI programs show their results in the form of ListBoxes, whose content is mainly textual semantically, but very often cannot be copied/pasted as text and neither is easy to export as text. I have one case in FreeFileSync, that shows lists of files upwards of 500'000 items, and other deduplicators programs.
I am having a general curiosity about this problem in linux.
Can a root user access, in read only mode, to memory associated to another (plain user mode) process ? Or the outcome is invariably a seg_fault ? Has a root user the right to inquire the memory of non root programs ?

I believe not.
In such cases it is usual to write a daemon to handle *all* requests.
   I am not speaking about disk files, but specifically in

physical memory

 Well thereby hangs a tale. In fact i deliberately created a RAMDISK in one application purely to handle communications between synchronous processes.
 One process writes it, others may read

   In many Linux distros now, /tmp is a de-facto
   ramdisk - all disappears on reboot. IF you have
   the space in your / partition then you need not
   specifically create a NEW ramdisk to achieve the
   effect.
   I've done it both ways over the years.
   Also look into "pipes". They've been useful at
   times (but a bit less flexible than the on-'disk'
   file approach). Wrote a nice little bi-di multi-
   user socket server using pipes (in Python and
   then 'C') so the 'parent' could convey a few
   important lists to the 'child' and vice-versa.
   Pipes basically ARE temporary in-ram files, but
   managed more automatically and systematically by
   the language/system library routines.
   In this case the server COULD actually send commands
   and info autonomously to the client so, I guess,
   in a sense they were both clients AND servers.
   Still have the code - might be interesting to refine
   it a little more. Pushing "status" info to the clients
   as needed is the best use IMHO ... "User X is sending
   you a 'friend' request ..."
   There are lots of client/server demos on the net,
   from the stupidest blocking send-wait kind to the
   high-traffic pre-forked/threaded variety. NOT hard
   to expand them into something good. Great fun.
   At current, I think "pre-threaded" holds the speed
   record ... the server creates like a dozen images
   of its important stuff at start-up so they're ready
   and waiting and can then increase from there as needed.
   It's maybe the most 'complicated', but not to the point
   of being incomprehensible levitating-guru-only.