Password protecting a directory? How?
 

Hey folks.

Is there any way to password protect a single directory? If it helps, I'm running SuSe 8.2.

EDIT: Okay, there was a miscommunication. I'm trying to protect a web page so that you need a password to access it. Should be easy enough with .htaccess. But I'm following these instructions to the letter, and not getting anywhere. I set up the name and password okay, and I get prompted like I want to, but the computer rejects my login and password. I know I have the username and password right; I'd set them mere second prior.

What's going on?

EDIT (AGAIN): Never mind, I figured it out. I had the pathname to the .htpasswd file wrong. Silly me.

thrifty; do not know specifically about suse nor security but have u taken a
observing close look at the howto,s they have a security section if expaneded will give detail information. may cover issues u seek. at http://tldp.org/HOWTO/HOWTO-INDEX section from table of contents 4.6
programming subsection 4.6.6 Security. try it may find what u search.

I guess in principle it should be enough to just change the permissions for the directory; especially uncheck the permissions for "others". Perhaps change the owner/group of the directory if it's necessary.

Remember that if you make all files under a directory unwriteable, they would still be eraseable if the directory has write permissions. When you delete a file you change the directory not the file. Funny, eh? :)

Are you sure about that Bebo?

rmdir won't remove a directory unless it is empty. And "rm -r" will only delete files that you have write permissions for. You can force it (which will only work if you are root or the owner) but it is just like you could force the deletion of any one single file.

One interesting thing is permissions like this.
umask owner group file
----r--rw- bill users /foo

In this case, bill will not be able to read or write this file even though he owns it. All the users on the system will only be able to read it. And anyone who is not bill or a user can read and write it.

This works because permission checking works in this order: if the person owns the file it will use the user bits (AND only those bits)... if the person is not the owner but is in the same group it will use the groups bits (and only those bits)... if the person is not in either of those catagories it will use the other bits.

A fun little quirk. Not sure which flavors might have worked around this but it has been that way from Unix V6 (earliest code I have access to) and continues through the BSDs today. Since Linux is not derived it might be different but I doubt it. Enjoy.

Note: This is not a bug... it is a feature. ;) Seriously, it is supposed to be that way. Part of the way unix permissions were defined. So I suspect it would work that way on Linux as well. But who knows...

I'm not perfectly sure, cause I haven't tried it :) But I did read it somewhere where I knew (or at least felt that) the source was to trust. Some place like hackinglinuxexposed.com or similar. Darn, I don't remember... :rolleyes: It was like this: you were unable to view the directory contents, but you could still delete the file if you knew the exact path to the file you wanted to delete. It might have been that the dir was -w- and the file was rw for you. But why anyone would set the permissions like that is beyond me :)

Ah, your thinking of this scenario.

directory /foo with permissions something like drwx--x--x
containing a file quux with permissions like -rw-rw-rw-

In this case you cannot do an ls of foo if you do not own it. (If the x's weren't there you couldn't even cd into it). But if you know quux is there you could delete it by specifying the complete name:
rm /foo/quux
You can also read and edit it as long as you specify the complete name. It is actually wise to change the permissions of your home directory to something like this if you are on a shared system.

I can explain why the other thing won't work but it is very geeky... in short everything in *nix is a file... absolutelly eveything, without exception! Except directories. :D In many ways they act like files but they are not. Yep, your sound card doesn't have an inode but it is a file. Each directory does have an inode but it isn't a file. It is one of the unix paradoxes... but is essential to ensure the stability of the system.

No one, not even root, can write into a directory. Even if they have write permissions. All changes to directories are done through system calls which perform their own permission and sanity checking. This is why you can't rmdir a directory with something in it (the system call fails).

Even if you could find a way to delete/edit the directory (like umounting the disk, finding the entry, and editing it by hand. The files will still be there. When you next run fsck (which will probably happen soon after you mount the disks and your kernel panics because the file system isn't consistent)... it will discover inodes which are not associated with any directory entry and create an entry for them in /lost+found (at the root mount point for the device /usr/lost+found whatever). These files will retain the original permissions, owner, etc. Only the name and path will be lost.

So, even if you managed to mangle to writable directory the files would be fine... just moved. Aint un*x/linux cool. :cool:

Yep, definitely :cool: That was really interesting reading :)

aah n therefore the great stability of the beast. what a good looking beast,
LINUX! thank you gentlemen.