I'm running a Debian Sid box with the 2.6.18-4 kernel. I created a 1gb encrypted image file with the following commands (as root):
Once the file was created, I made two scripts, open and close, to access the encrypted file system.

open:
close:
Also, I've added the following entry into /etc/fstab:
When I run these scripts as root, it mounts the file system just fine, and I can access it read/write as root, but I have read only access in my normal user account (crashsystems). I would like to be able to access the file system without giving my root password first, but most importantly I need to be able to have read/write access to it with a non-root account. When I try to run the open script as crashsystems, I get the following error:
I've checked out the permissions set on the binaries for mount, umount, losetup, and cryptsetup, and made sure that they were executable by everyone, but to no avail. If anyone knows what I might be doing wrong, that would be great.

That would indicate to me that you don't have sufficient permissions on /dev/loop0. Check the permissions on the loop0 device file and see if you can change them for all users to have rwx permissions, i.e.:

# chmod 777 /dev/loop0

and then see if you can open the encrypted filesystem as a regular user. Note of caution, I'm not sure what the possible security ramifications are for changing the permissions on loop0. Also, the permissions on loop0 may reset to their default status on reboot.

kilgoretrout, I changed the permissions as you suggested, and that solves the permission denied problem for /dev/loop/0, but I'm still getting the rest of the message.

I think you may also need write permissions to the /dev/mapper directory.

Adding write permissions diden't change anything. Have any other ideas?

Here's the problem as I see it. You have given ordinary users execute permissions on losetup, cryptsetup, mount and umount. However, the processes launched by these commands have a set of permissions attached to them just like users do. The general rule is that a process will have the same permissions as the user that launched the process. Unfortunately, all these processes have to do certain things that only root can do in order to generate the device file in /dev/mapper and mount the encrypted filesystem. You could probably get around that by changing the permissions on those commands to SUID root:

# chmod 4755 <full path to command>

This will cause the command to launch with root permissions instead of the user's permissions. This is also generally considered an insecure practice.
You can also accomplish much the same thing in a more secure manner with sudo. Here's a nice article going into how to set sudo up:

http://polishlinux.org/first-steps/r...ount/sudo-faq/

However, your main problem seems to be that you want ordinary users to have write access to the encrypted filesystem. You generally would accomplish that on a linux filesystem by first mounting the filesystem and then running:

# chmod -R 777 <mount point>

I would suggest mounting the encrypted filesystem as root and running:

# chmod -R 777 /home/crashsystems/Secure/files

This would work on any normal linux filesystem. It is imperative that the filesystem be first mounted before running the command or it won't work.

Changing the mount point permissions post-mount did the trick. I'll probably set up sudo for the task eventually. I was thinking though, could I just chown root my open and close scripts, and make them writable only by root, then set up the sudo stuff for those scripts. Do you think that would work? Thanks for your help.

I know SUID does not work on bash scripts, i.e. you can't set the permissions on a bash script SUID. It's just way too insecure and automatically not allowed on scripts; you need a compiled executable binary for SUID to work properly. I'm not sure about sudo but my guess is you can get it to work on scripts. If not, you probably just need to deal with losetup and cryptsetup.