DSL Tips and Tricks :: customizing emelfm



I'm a big fan of rox, but I also use emelfm for a lot of things. One of the things I like about emelfm is its ability to be customized and configured however the user wants via adding various applications to the "choose action" option (right click) or adding buttons to the middle pane to manipulate files, launch scripts, etc., however the user wants.

To get more application options to open various files, just right click on a file of the type you want to change or add associations, select "edit filetype," and add whatever application(s) you want to associate with it. Then you just have to right click and scroll to "open with" and you get your choices. I've added various editor options to open text files, GIMP and xv for image files, Open Office and Gnumeric/Abiword options for spreadsheets and documents, SeaMonkey for HTML, etc.

Adding buttons is just as easy. I needed to encrypt some files scattered about in a few directories, so I added a button to emelfm to help do that faster (and also added a decrypt button). I've posted the steps at the link below. The process is the same for whatever buttons you might want to add.

http://lucky13.blogsavy.com/dsl-add-gpg-buttons-to-emelfm/
Quote (lucky13 @ Mar. 24 2007,16:32)
I'm a big fan of rox, but I also use emelfm for a lot of things. One of the things I like about emelfm is its ability to be customized and configured however the user wants via adding various applications to the "choose action" option (right click) or adding buttons to the middle pane to manipulate files, launch scripts, etc., however the user wants.

To get more application options to open various files, just right click on a file of the type you want to change or add associations, select "edit filetype," and add whatever application(s) you want to associate with it. Then you just have to right click and scroll to "open with" and you get your choices. I've added various editor options to open text files, GIMP and xv for image files, Open Office and Gnumeric/Abiword options for spreadsheets and documents, SeaMonkey for HTML, etc.

Adding buttons is just as easy. I needed to encrypt some files scattered about in a few directories, so I added a button to emelfm to help do that faster (and also added a decrypt button). I've posted the steps at the link below. The process is the same for whatever buttons you might want to add.

http://lucky13.blogsavy.com/dsl-add-gpg-buttons-to-emelfm/

Interesting, thanks.  :-)

As a side-issue, I wonder if DSL still uses/creates RAM disks fairly seamlessly, regardless of how it's been installed?  If so, do the contents of a RAM-disk ever get shunted into swap?

I only ask because some encryption software is *very* careful not to write cleartext to disk, ever, not even temp-files, and will only decrypt into RAM.  This has its benefits in enhanced security (prevents data recovery tools from finding deleted cleartext on disk later), but can be a pain in the ass when you want to export data to another program.  I have one program, a password database manager that's much more paranoid than I'd ever want to be, and that can be a nuisance sometimes.

Anyway, since emelfm's a file manager, of course you'd use it to encrypt *files*, and decrypt *files*.  But reading and writing these files to RAM, saving only the encrypted copy to disk might be helpful for the more security-concious out there -- or simply if the cleartext in question is especially sensitive.  Seems that would add some high-security benefits, with fewer drawbacks.


Just a thought,

Patrick.
Quote (the Missing M @ Mar. 25 2007,04:34)

As a side-issue, I wonder if DSL still uses/creates RAM disks fairly seamlessly, regardless of how it's been installed?  If so, do the contents of a RAM-disk ever get shunted into swap?

RAMdisk is set up in /etc/init.d/knoppix-autoconfig:

Code Sample
# Increase ramdisk to include swap from friedgold of the DSL forums
if ! checkbootparam "toram"; then
  if [ -z "$INSTALLED" ]; then
      # Now that any swap partitions/files are mounted, see if we can increase the ramdisk size
      RAMSIZE="$(expr $FREEMEM \* 4 / 5)"
      [ -n "$RAMSIZE" ] && mount -o "remount,size=${RAMSIZE}k" /ramdisk
  fi
fi


So the answer is yes.
Quote
I only ask because some encryption software is *very* careful not to write cleartext to disk, ever, not even temp-files, and will only decrypt into RAM.  This has its benefits in enhanced security (prevents data recovery tools from finding deleted cleartext on disk later)...

GPG will give warning messages about this if its SUID isn't set to root.

From the above link:
Quote
Now that you know the program is installed, your first step is to secure how it allocates memory to nonroot users. GPG requires that most Linux systems run it as SUID root. Any application allocates pages of memory from the system, and GPG wants this memory to be secure. Otherwise, an illicit user could capture this memory and then gain access to the information you are going to encrypt. In order to secure these memory pages, GPG locks this memory before using it. It needs to run as root to lock the memory. As soon as this is done, GPG then runs under the permissions of the owner.

The SUID is set to root in the MyDSL extension (which needs to be updated).
Quote
Anyway, since emelfm's a file manager, of course you'd use it to encrypt *files*, and decrypt *files*.  But reading and writing these files to RAM, saving only the encrypted copy to disk might be helpful for the more security-concious out there -- or simply if the cleartext in question is especially sensitive.  Seems that would add some high-security benefits, with fewer drawbacks.

Someone who's that aware of criticality and security should already make presumptions based on his own system's configuration, and probably has a very specific protocol that wouldn't use emelfm in the first place. Or should have a stricter protocol if his needs demand it, anyway. For rudimentary signing/encrypting purposes, this should suffice. For more critical purposes, you would want to take stricter, more secure action than simply encrypting a file that results in a similarly named file with a gpg extension in the same directory -- you still have the unencrypted file on the hard drive regardless what's "detectable" in swap.
Quote (lucky13 @ Mar. 25 2007,01:55)
Quote (the Missing M @ Mar. 25 2007,04:34)

As a side-issue, I wonder if DSL still uses/creates RAM disks fairly seamlessly, regardless of how it's been installed?  If so, do the contents of a RAM-disk ever get shunted into swap?

RAMdisk is set up in /etc/init.d/knoppix-autoconfig:

Code Sample
# Increase ramdisk to include swap from friedgold of the DSL forums
if ! checkbootparam "toram"; then
  if [ -z "$INSTALLED" ]; then
      # Now that any swap partitions/files are mounted, see if we can increase the ramdisk size
      RAMSIZE="$(expr $FREEMEM \* 4 / 5)"
      [ -n "$RAMSIZE" ] && mount -o "remount,size=${RAMSIZE}k" /ramdisk
  fi
fi


So the answer is yes.

Ah, okay.

Quote
Quote
Anyway, since emelfm's a file manager, of course you'd use it to encrypt *files*, and decrypt *files*.  But reading and writing these files to RAM, saving only the encrypted copy to disk might be helpful for the more security-concious out there -- or simply if the cleartext in question is especially sensitive.  Seems that would add some high-security benefits, with fewer drawbacks.

Someone who's that aware of criticality and security should already make presumptions based on his own system's configuration, and probably has a very specific protocol that wouldn't use emelfm in the first place. Or should have a stricter protocol if his needs demand it, anyway.

Well yeah, it's down to the user, and how secure they want to be.  That was more a suggestion on ways to use it, than how to improve on what you'd already done.

Quote
For rudimentary signing/encrypting purposes, this should suffice. For more critical purposes, you would want to take stricter, more secure action than simply encrypting a file that results in a similarly named file with a gpg extension in the same directory -- you still have the unencrypted file on the hard drive regardless what's "detectable" in swap.

True.  That's where editing the cleartext version on a RAM-disk came into it.  It seemed fairly easy.


Patrick.

original here.