Go Back   FlashFXP Forums > > > >

ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD.

Reply
 
Thread Tools Rate Thread Display Modes
Old 02-06-2014, 09:16 AM   #1
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default Lock user to home directory

Hello,

i wonder how i can lock guests to their /GUESTS/username home directory. I defined this property for the specific user, but it is possible to walk the tree up. I don't want to allow this. How to achive this?
mantonio1965 is offline   Reply With Quote
Old 02-07-2014, 12:44 AM   #2
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

There isn't a trivial switch you can flip to lock a user to their home directory. I've thought about such a feature for a while, but never got around to it.

You can however do something like this: give all users who are supposed to be locked into just their home directory a user flag like J for jailed or something. Mark all the top level dirs (besides /GUESTS !) as private with perms like "!J *" so everybody but people with the J flag should be able to see/use it. Assuming guests shouldn't be able to see other guest's dirs you can mark them as hidden to all but them as well with something like "1 -<username> !*". The 1 means regular SiteOps can see the dir. V flagged VfsAdmins and Master accounts will always see the dir no matter what.

If you do that a guest user with the J flag should only see /GUESTS from the root, and under /GUESTS only their own home directory. I think that's what you want. The only tricky part is to remember after you create each new jailed user to mark their home directory as hidden to all but them. I'd just make a macro in your FTP client to do this for you. In FlashFXP for instance you can ask for a username then create that dir, hide it, and then create the user, change the home dir, etc.

I'd also suggest you create a new group like Guests and put all the guest users into it. If you do this you wouldn't technically even need the J user flag since you could just test for group membership in Guests via =Guests or !=Guests instead of J and !J. The benefit of the group is you can use site gadduser Guests in your macro to add guests right into the Guests group which could have custom user defaults. Check out site help gadduser and site help /Defaults but I believe it's /Default=<groupname>. The site groups command can show you which groups have been customized to not user the regular /Default.User template. Use 'site uinfo /Default.User' or /Default=<groupname> to see the defaults.

The one thing I can't prove without testing is what happens with relative symlinks. Only VfsAdmins can create them but if you use something like "../../foo" that may or may not allow you to link to a dir not under your home dir. The idea here was you could expose selective parts of your server to a user in a custom home directory. This was in preparation for the jailed user feature instead of this workaround I just described, but I just don't remember how it works or if it handles everything properly. I know it doesn't stand a chance of working unless the keep_symlinks or whatever option is enabled, but I only mention it in case it's really useful for you. There is a workaround that uses NTFS junctions / hard links but requires certain other settings be changed from their default and I don't really suggest using junctions this way unless you know what you are doing.
Yil is offline   Reply With Quote
Old 02-07-2014, 07:46 AM   #3
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default

Hello Yil and thanks for the reply.

I fact i used to create the users using gadduser and put them in GUEST group. However, when i use the user's login to check what it can see, i am able to walk all the way up to site root and see all the folders on site. I am not very familiar with ownership and making things visible/accessable to specific groups/users only. All the 1st level directories /* are owned by ioftpd/ioftpd. The /GUESTS folders ownership was set to ioftpd/GUEST as i thought that means the admin user owns this folder and all GUEST group members only may access it.

In fact it is what you mentioned that i want to achieve. If a GUEST user logs in, it must not see any other folders than /GUESTS and within /GUESTS only its own folder.

I have to play around with what you mentioned to see if i can get it and make this working for me. Guess i have to come back and ask a little more.
mantonio1965 is offline   Reply With Quote
Old 02-08-2014, 04:55 PM   #4
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

The first thing to understand is that ioFTPD supports both user and group level permissions for directories much like any unix system does. In particular a user must have +r access to a directory in other to enter it, and +w to modify it (+x is ignored, just use +r). Fine grained control over what a user can actually DO in a directory they can enter is controlled by the VFS rules in the .ini file. This gives you enormous flexibility and control since you can have unlimited VFS rules that apply to different paths as needed. Just using 'site chmod' to modify the user and/or group +r/+w settings should allow you to control where people can go. This would absolutely allow you to lock users to particular directories and is very straightforward as you would simply change user's home directories to be owned by them, chmod 700 the dir so only the owner can enter it, leave /guests and / at 555 and leave everything else owned by ioftpd group (I'd user a different one as ioftpd is the default group) and just make sure users are in only the GUESTS group. That should do what you want and is indeed how a regular unix system would probably set up the permissions. For the record you must have +r permissions to access any path all the way from / to the directory. Thus if you have /games/archive and /games has perms of 550 owned by ioFTPD/ioftpd (the default) and the user isn't a member of the ioftpd group then the user will be able to see /games from / but will not be able to enter /games or see anything under it even if /games/archive has 777 as the perms. Hope that makes sense. Also check out he default VFS perms for files/dir in the .ini file and set that appropriately if needed.

However, I just got finished answering a different question for someone else so I might have steered you a little wrong with my above answer. I believe they wanted to hide the existence and names of the other users. Using +r/+w perms you can control who can enter/modify a dir but you can't hide the existence of the dir or who owns it because it will show up in a directory listing. To do that you have to use the answer I showed you above which uses 'site chattr +h' to make directories private/hidden so if you don't match the permissions on the directory it won't show up at all!

Let me know if that helps, or if you need more info.
Yil is offline   Reply With Quote
Old 03-29-2014, 02:10 PM   #5
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default

Thanks for your explanation, Yil. This is very explanative and i have to play around with it to understand.
In fact i already tried to fine tune the sections acl via the VFS rules, but it seems not as intuitive and self explanatory as i'd like to have it. Also your hint, to chmod the document root / to 555 seems impossible to realise since i dont have access to the root folders attributes from within FlashFXP. I can chmod any subdirectory to what i like. How would i access the root folder?

Regarding the VFS let me explain what i want with the following example. Lets say i have this structure

Code:
/Section/2014/2014-01/0101/subdirectory
1) The level of the 'Section' folder must be creatable/deletable/renamable via script or VM-users only
2) The level of the '2014' folder must be creatable/deletable/renamable via script or VM-users only
3) The level of the '2014-01' folder must be creatable/deletable/renamable via script or VM-users only
4) The level of the '0101' folder must be creatable/deletable/renamable via script or VM-users only
5) The level of the 'subdirectories' folders can be creatable/deletable/renamable/uploadable/resumable via 3-users and higher
6) No further directories must be creatable within a subdirectory

Here is how i understood the VFS and tried to integrate the ACL.

MakeDir = /Section/[0-9]+/[0-9\-]+/[0-9]+/* 31VM
MakeDir = /Section/[0-9]+/[0-9\-]+/* VM
MakeDir = /Section/[0-9]+/* VM
MakeDir = /Section/* VM

Delete = /* 1VM
DeleteOwn = /* 31VM
MakeDir = /* 1VM
#Overwrite = /* 1VM
RemoveDir = /* 1VM
RemoveOwnDir = /* 31VM
Rename = /* 1VM
RenameOwn = /* 31VM
#Resume = /* 31VM
#Upload = /* 31VM

But this does not work no mather how i try. I don't understand if it is my expressions or a misunderstanding of the concept.
What i want to achive is that nobody but the VM-users can create directories directly under / and /Section. Under the section come the day dirs and users should be allowed to CRUD under the last date dir and only within this level.

Would you mind to explain in depth how to implement this?
mantonio1965 is offline   Reply With Quote
Old 03-29-2014, 05:54 PM   #6
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

ioFTPD doesn't support regular expressions for path matching. It supports unix-style command line path matching where * matches anything or nothing, ? matches any single character, and [] and [^] match any single character in or not in the group. This explains why the [VFS] rules aren't doing anything for you

Let's use your example of: /Section/2014/2014-01/0101/subdirectory

I'd just stick with the default VFS rules for /*. I'd suggest you do something like.

site chown ioFTPD:ioftpd /
site chmod 755 /
site chown ioFTPD:ioftpd /Section
site chmod 777 /Section (or perhaps 775 in some cases).

The root dir (/) tends to get stuff uploaded to it when scripts freak out so I like it read-only most of the time.

NOTE: You don't want to use -R to recursively set perms/ownership, but you might want to use * from within a dir to do all immediate subdirs.

NOTE: M flagged users are the only one who don't have ANY perm checks applied to them when dealing with filesystem perms (rwx stuff). V flagged users can SEE everything but if they attempt to do something directly requiring write permissions it will be denied. This is a safety feature. They of course have the ability to use chmod to make whatever they need to do writable and THEN delete it but it's a 2 step process on purpose. Most of the time this isn't an issue since they'll just use 'site wipe' to delete stuff anyway and the idea was site wipe would protect you from doing things you shouldn't be doing without realizing it.

NOTE: When you create a directory from inside the FTP it inherits the permissions of it's PARENT dir. Thus if you manually create /Section/2014/2014-01/0101/subdirectory the new sub will have the same perms (rwx's) as 0101. This is important if you have a /Games dir with games getting put directly into it because it must be 777 for regular users to create dirs in it! It's up to scripts (say nxTools newdate feature) to do whatever it wants if it creates a dir itself.

So here's the tradeoff you need to think about at the moment. None of the new-day scripts are really good about handling a server that is offline when the newday event should run especially if it's missed more than the most recent. Thus it's sometimes necessary to manually create dated or even a monthly dir. In that case it's easy to forget to +777 the dir if you were using 775 on it's parent, so I'd just go with 777 everywhere but root...

Now back to your original problem, if you want to protect uploads to dated dirs try these rules:
MakeDir = /Section/[0-9][0-9][0-9][0-9]/[0-9][0-9][0-9][0-9]-[0-9][0-9]/[0-9][0-9][0-9][0-9]/* 31VM
MakeDir = /Section/[0-9][0-9][0-9][0-9]/[0-9][0-9][0-9][0-9]-[0-9][0-9]/[0-9][0-9][0-9][0-9]/ 1VM
MakeDir = /Section/[0-9][0-9][0-9][0-9]/[0-9][0-9][0-9][0-9]-[0-9][0-9]/ 1VM
MakeDir = /Section/[0-9][0-9][0-9][0-9]/ 1VM
MakeDir = /Section/* VM

I think that should work. The trailing / should mean it must be a dir that exactly matches, whereas a trailing /* means any path which matches at least that far.

That only leaves the subdir of the last dir problem. You can sometimes use a zipscript like ioNiNJA to only allows certain dirs to be created in certain sections. Where that makes sense I'd use it. Or you could try another rule before the others like:
MakeDir = /Section/[0-9][0-9][0-9][0-9]/[0-9][0-9][0-9][0-9]-[0-9][0-9]/[0-9][0-9][0-9][0-9]/*/* !*
which should prevent subdirs of the dirs in the dated tree...

Let me know if this works for you and/or makes sense
Yil is offline   Reply With Quote
Old 03-29-2014, 06:21 PM   #7
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default

Thanks Yil for the fast response. I am currently refactoring the permissions on whole site as i regularly encounter problems with folder attributes and symlinks created by ioNinja. Sometimes it even creates deadlocks (symlink to a folder within the target folder) and plenty other crazy stuff. The most important problem however is the creation of wrong chmod onUploadComplete which is why i completely removed all HDD mapping within default.vfs and freshly created the first level subdirectories in io-root folder just to narrow the problem.

The root to first level structur is now completely like you suggested

Code:
site chown ioFTPD:ioftpd /
site chmod 755 /
site chown ioFTPD:ioftpd /Section
site chmod 777 /Section
In default.vfs i testwise defined a map to another HDD for the 'Section' folder.

Code:
"Z:\test" /Section
Uploading without any script enabled works well. But with ioNinja enabled no matter what i do, all stuff that is getting uploaded into /Section/subdirectories ends up with chmod 7. The folder attributes in FFXP show

Code:
d------rwx
This is making me headache for years now and i cannot figure out how it come. I cannot continue to fine tune the whole sections area until this is reliably fixed.
mantonio1965 is offline   Reply With Quote
Old 03-29-2014, 06:28 PM   #8
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Careful now... You need to understand how unix style directory permissions work.

drwx------ -> OWNER perms
d---rwx--- -> GROUP perms
d------rwx -> EVERYONE perms

You want to 'site chmod 777 /Section' to get to drwxrwxrwx which should make things look/work better as what you have now is essentially 007 which doesn't make a lot of sense...
Yil is offline   Reply With Quote
Old 03-29-2014, 06:33 PM   #9
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Another tidbit... In FlashFXP use the view raw directory menu option and examine the permissions for the "." folder to see what the perms/owner for root (/) are. Then double check that /Section and . from inside (cwd) /Section are the same and then see if 'site refresh /' or 'site refresh /Section' make any difference if they look different.

If you have a /Sample directory under / in the windows filesystem and you have a mountpoint in your vfs for /Sample to another disk things can get a bit tricky in some rare cases so double check that isn't happening.
Yil is offline   Reply With Quote
Old 03-29-2014, 06:49 PM   #10
mantonio1965
Member
 
Join Date: Aug 2007
Posts: 37
Default

Quote:
Careful now... You need to understand how unix style directory permissions work.

drwx------ -> OWNER perms
d---rwx--- -> GROUP perms
d------rwx -> EVERYONE perms
This topic is clear to me

Quote:
You want to 'site chmod 777 /Section' to get to drwxrwxrwx
This is exactly what i did after reading your last post and like i quoted in my previous post.

Quote:
what you have now is essentially 007 which doesn't make a lot of sense...
Right, and this is calculated by ioNinja zipscript at some stage. I am currently debugging it down the route finding the place where upload processing is done just to check the code that calculates the final attributes to set.

Here is the RAW output for the discussed stuff. It shows what you suggested
Quote:
drwxr-xr-x 26 ioFTPD ioftpd 0 Mar 29 21:53:25 2014 .
drwxrwxrwx 4 ioFTPD ioftpd 0 Mar 29 23:42:15 2014 Section
And here is the RAW output from within the uploaded subdirectory
Quote:
drwxrwxrwx 3 ioFTPD ioftpd 0 Mar 29 23:47:54 2014 .
drwxr-xr-x 26 ioFTPD ioftpd 0 Mar 29 21:53:25 2014 ..
d------rwx 2 user GRP 9725283 Mar 29 23:47:55 2014 Subdirectory
This is absolutely unclear to me

UPDATE:
I think i figured out what caused this issue. With the ioNinja parameters set ioNJ(group_status) and set ioNJ(group_genre) both set to 1 the above mentioned problem occurs. With both set to 0 the problem seems fixed. I uploaded several subdirectories and found all ending up with chmod 777.
I should now find a source where site addgrpstat and site addgroups are explained in more detail as o_dog claims to have called both commands before setting these parameters to 1. But i wonder why they are set to 1 by default if they depend on the site commands being called first.

Last edited by mantonio1965; 03-29-2014 at 07:07 PM.
mantonio1965 is offline   Reply With Quote
Old 03-29-2014, 10:47 PM   #11
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Glad to see you are narrowing the issue. It's possible o_dog's script needs a tweak, but it's possible this is actually the fault of a change in ioFTPD's TCL interface that I didn't even think of but o_dog caught as a bug. That was a while ago, but perhaps it's not a commonly used option and it's didn't get updated as well.
Yil is offline   Reply With Quote
Reply

Tags
directory, home, homedirectory, lock, user

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 06:57 AM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)