Setting permissions for users

[LundeSDK]

Hey.

I want to set permissions so standard users (3) have acess to Upload, Resume and MakeDir. I have tried to set the settings in the ioFTPD.ini file, but no success.

Which procedure should I use, to make this work?

[Yil]

Going to need a bit more information. The .ini file can certainly limit who can do what where, but you still need access rights in the VFS itself. I.e. you'll need 0777 directory mode or rwx for the directory you want to upload to/makedir under for non-owner/non-group users of the parent.

As of v7 the permission denied message should indicate which setting caused the denial. Check the error message and compare the text in the ()'s to what the Changelog says...

[Smirnoff]

Hello,

I would like to setup a “corporate” ftp site using ioFTPD (as it is stable, performant, support ssl,…)
I also struggle a little bit with the permissions, so I’m hijacking this new thread about the same subject hoping it wil also answer LundeSDK problem.
(if not ok just tell me so I’ll open a new thread):

The aim is:

Anonymous users
- can download whatever is on the ftp site
- Upload dir should be restricted: customers can upload their debug files but should not be able to download from there (or even better cannot list the content of that dir)

Contributor users
- Can download whatever is on the site
- Can upload in a specific dir (/Products) create/delete their own dir/files
- Upload dir: can download/upload (Not mandatory)

Actual Setup:

I’ve left the default permissions:
Default_Directory_Attributes = 755 0:0
Default_File_Attributes = 644 0:0

I created 3 separate vfs files :

External for anonymous users (Flag A)
Contributor.vfs for contributor users (Flag Q)
Webmaster.vfs for the webmaster - I won’t discuss this case as it points to other dirs

Both external.vfs and Contributor.vfs got:

"E:\ioFTPD-v7.0.3\FTP-ROOT-DIR" /
"E:\FTP-Content\Product" /Product
"E:\FTP-Content\Upload" /Upload

In ioFTPD.ini, I’ve set:
Upload = /Upload/* 31VMA
Resume = /Upload/* 31VMA
MakeDir = /Upload/* 31VMA
DeleteOwn = /Upload/* 31VMA
RemoveOwnDir = /Upload/* 31VMA
Upload = /Product/* 1VMQ
Resume = / Product /* 1VMQ
MakeDir = / Product /* 1VMQ
DeleteOwn = / Product /* 1VMQ
RemoveOwnDir = / Product /* 1VMQ
Rename = /* 1VM
RenameOwn = /* 31VM
Overwrite = /* 1VM
Delete = /* 1VM
RemoveDir = /* 1VM



My problems:
- Anonymous can list the content of /Upload and above all download whatever there is
- Contributor cannot create a dir or upload in the /Products dir (error message is: [1] 550 fze: Permission denied (directory mode).

What am I missing there ??

Is there anything like this to restrict download rights:
Download = /Upload/* 1VM


Thanks for your help
Smirnoff

[Yil]

When dealing with an anonymous account or an account/password that are shared/well known (i.e. my FTP server setup for users to upload crashlogs/minidumps where everyone shares an account) the best way to make sure people can't download information sent by someone else is to use .ini file permissions. Look again at the .ini file just a few lines below where you were before and you'll see

# anybody can download anything...
Download = /* *

The way the .ini files works is lines are processed top to bottom and the first match for the operation based on the path is used. Thus just add the line you actually suggested "Download = /Upload/* 1VM" above the more generic one and that will restrict users without the 1VM flag from downloading in the /Upload dir but allow them everywhere else... If you've already added the line and it didn't work, make sure you used "site rehash" and that you added the line BEFORE the /* one. The rest of the .ini can just use the default values in the original. ini file or you can customize more like you have done (though I haven't checked your settings here).

My problems:
- Anonymous can list the content of /Upload and above all download whatever there is
- Contributor cannot create a dir or upload in the /Products dir (error message is: [1] 550 fze: Permission denied (directory mode).


The .ini file is not involved in those 2 problems. To restrict entering the /Upload directory you want to change the directory mode (rwx) flags. In particular you can use something like 0770 which is rwxrwx---. The command is "site chmod 770 dirname" and if you are using Flash it has a nice little popup you can use to do this. You only need to change the /Upload directory itself, and not everything recursively under it. Using something like that will only allows the owner or any account that is a member of the group for the directory to access it, but other users such as anon users won't have any ability to enter/list/etc provided they aren't in the same group as the directory...

The /Products error is the reverse problem. The default perms of 0755 only allows the OWNER (probably you or ioFTPD account) to create directories immediately beneath it. While that is a good default setting for the / directory it's not so useful for something like /Products. I'd suggest you "site chmod 755 /" and then change the default to the more liberal 777 mode which allows anyone to do anything anywhere. That may sound bad, BUT they must also pass the action test from the .ini rules. Thus users can't remove stuff unless they match the Remove rule. So just add the Q flag if you want them able to remove stuff, or leave it 1VM is you only want admins to.

I hope that helps a little bit. In general you probably don't need separate .vfs files and can control access through rwx flags and control operations through the .ini.

[Smirnoff]

Hello,

Wonderfull explanations :)
The way the .ini files works is lines are processed top to bottom and the first match for the operation based on the path is used.
That must be the poitn I've missed when trying to setup my config.

I'll go for the chmod 755 and then set 777 in the ini file.

I already got the anonymous working smoothly. they can list the content but cannot download from /upload:

[1] RETR dump.rar
[1] 550 dump.rar: Permission denied (directory mode).
[i] Transfer Failed: dump.rar
[i] Failed 1 file(s) and Skipped 0 file(s)

Funny stuff is that it creates a 0b file on the client computer when trying to download. No biggie there for me.

About the separate .vfs file: I'm working that way so far as the teams still need to define their needs and procedures. I already suspect they will need some extra dir in the / that anonymous users won't be supposed to see.

Awesome job with ioftpd. Its granularity makes it a 1st choice for me :)

Cheers
Smirnoff