ProFTPD and SSH: weird permissions error?


I currently have openSUSE 11.4 64-bit installed in server (text) mode inside a VirtualBox VM, running on a Windows 7 64-bit host machine. The virtual network adapter is currently running in bridged mode so it can get a proper IP address from the host network. I’ve been fiddling with the user/group ownership concept in UNIX-based systems (trying out new information I’ve learned :)) by changing the user/group that owns a particular file/folder and their permissions using the ‘chmod’ command, then testing out the new ownership/permissions by trying to perform prohibited actions such as deleting a folder. I’ve tried this out in different scenarios to see how strictly these permissions are enforced. Before I go into more detail about this here is some relevant info on the current setup of the virtual machine I’m running:

  • I have created a new user called ‘test’, which belongs only to the system group ‘ftp’ at the moment. Don’t know at this stage if this makes any difference to my below issue.

  • Samba and ProFTPD are currently installed and running, and the user ‘test’ has been created for each. Samba was installed from one of the default openSUSE repositories (don’t know which one has it) added during installation, ProFTPD was installed after manually adding the openSUSE contrib repo after installation.

  • In the home directory for the user ‘test’, there is a folder called ‘test-folder’ with the following parameters (obtained from issuing the command ‘ls -l’):

drwxr-x--- 2 root root 4096 Jun  1 16:29 test-folder

When the user ‘test’ is logged into their Samba share they cannot do anything to this folder - open it, rename it or even delete it. This is what I expect. When the same user is logged in either by SSH or through FTP however some strange stuff occurs as below:

  • In an SSH session I am blocked from opening the folder, but I can still rename or delete the folder (when trying to delete I’m prompted once to confirm I want to go into a write-protected directory, then once more to confirm I want to remove a write-protected directory).

  • When connected to the FTP server using Filezilla, I am stopped from deleting or opening the folder, but I can still rename it.

Is there something I’ve done wrong or overlooked, or is there a bug or incompatibility somewhere with something, or is that just the way it is?

Any help would be appreciated. Thanks.



I’m not sure I completely understand the problem.

It is normal unix semantics, that a user can rename something in a directory where that user has write permission. If the home directory for user “test” is writable by user “test”, then that use can rename “test-folder”.

In unix file system semantics, a file does not have a name. Rather, a file directory has a name that points to the file. It is the directory (home directory for user “test” that determines the name, rather than the file (or, in your case, directory “test-folder”) that sets the name.

Likewise, the owner of the directory can remove files from that directory. A non-empty subdirectory cannot be removed - you have to empty the subdirectory first.

If “samba” will not remove the subdirectory, it is probably because it is trying to follow Windows file semantics, where the file name is tied to the file instead of to the containing directory.

Incidently, this difference is file system semantics (between Windows and unix/linux) is why you don’t have to reboot your linux system whenever you do updates.

On 06/03/2011 01:06 PM, jonitfcfan wrote:
> drwxr-x— 2 root root 4096 Jun 1 16:29 test-folder

the user named test should have no directories owned by root in his /home

in fact, there should be nothing in /home/test which is not owned by
test and in the group named users

repair that and begin again…

and, please answer this (just because i am curious) what is the utility
of putting openSUSE in a Win7 hosted VM? (which, to my way of thinking
is putting the least capable, robust and secure system as the
foundation…what is the advantage of doing that?

[NNTP via openSUSE 11.4 [] + KDE 4.6.0 + Thunderbird 3.1.10]
Dual booting with Sluggish Loser7 on Acer Aspire One D255

Thanks for the replies,

I actually used the chmod command as root when currently in that directory to change the ownership of that sub-folder myself as part of my testing. As for your question, I was merely just setting up a temporary testbed at work to put into practice what I’ve learned up to now about UNIX file/folder ownership, and exactly how strictly (if at all) these permissions would be implemented when it came to running such servers as Samba or ProFTPD. Windows just happens to be the OS installed on my machine at the office. This was never intended to be a permanent setup.

OK. So what you’re saying is that because the user ‘test’ owns the directory ‘/home/test’, this means that they would actually own everything in it, even if the permissions for sub-folders/files within that folder say otherwise? Is this then overriding the permissions I set for the folder ‘test-folder’ to some extent; hence why I can still rename or delete the folder in an SSH session, for instance, despite the permissions defined for it?

If he owns the directory, then he owns all of the <i>names</i> in that directory. He can remove a named file from that directory, because he owns the directory. He does not own the files themselves. He cannot write to a file in that directory, unless he has write access to that file.

The “rm” (remove) command in unix/linux simply removes the directory entry for the file. It does not remove the file itself. There isn’t a unix command to remove a file. You can only remove a directory entry. The operating system removes files when there are no longer any directory entries for the file and no program has that file open.

User “test” does not own the files or subdirectories in “/home/test”. But he owns the names assigned by that directory.

Whether he can remove the subdirectory “test-folder” that is root owned, is a tricky issue, and possibly varies between unix versions. As far as I know, most unix-like systems do allow removal of an empty subdirectory that you don’t own. If the subdirectory is not empty, then you cannot remove it unless you have sufficient permissions to empty the subdirectory first. The trick to making a root-owned subdirectory non-removable by an ordinary user, is to put a root-owned file inside that directory.

Lol so the learning continues :,

So what this means is that in UNIX files and folders are separate entities to names that you would use to refer to files and folders, as opposed to how Windows effectively links the two together - is that right? Also when you say that ‘the operating system removes files when there are no longer any directory entries for the file and no program has that file open’, I’m assuming this is an automated process - is that right? If so does this happen as and when it needs to happen, or does the OS carry out routines checks from time to time for this sort of thing?

Thanks for the tip. I’ll have to try this out when I’m next in the office…

And thanks for helping to expand my general understanding of the UNIX file ownership concept. At least I know that it isn’t a bug after all :).

[EDIT]: Just one more question out of interest. You talk about needing sufficient permissions to empty the contents of a sub-directory before you can remove the sub-directory itself. Is there a UNIX command to empty a directory’s contents but keep the directory itself?

To do that, I normally “cd” into that directory, and then do:

rm -rf * .??*

That recursively removes anything in the directory that either does not begin with “.” or is at least 3 chars long but does begin with “.”. That usually takes care of it. But there could be a file such as “.a” left behind. An ‘ls -la’ takes care of looking for that.

If I just use “", that won’t match hidden file. If I use ".” then that match the current directory “.”, the parent directory “…” as well as other hidden files. I find that “.??*” works pretty well and usually matches all hidden directories.

On the other question - yes, the operating system automatically deletes files that are no longer accessible (no directory entry and not being read by a running program). If it ever misses one, then the next “fsck” will catch it.

A bit more on files. In unix, a file is defined by its inode. The inode keeps track of the information about the file. The directory entry just maps a name to an inode number.