FlashFXP Forums - View Single Post

Yil · 11-06-2007, 02:51 AM

There are actually 2 more hard coded flags.

L - always allow login (M implies L - just learned that!)
1 - inside the add user code M and 1 are tested to determine if the user is a pure admin or a group admin.

The G flag isn't hardcoded, it is simply a convention in ioFTPD.ini as neoxed points out. The problem is if you have the G flag but are NOT explicitly the groupadmin of any groups you are sort of considered a regular admin because the User_IsAdmin function allows that. I'm not sure if that is a long standing bug, or a historical artifact...

On the other hand if you ARE an admin of specific groups the code ALREADY limits all site change commands to members of those groups. In fact it was so limiting that I had to bypass the check in 6.3.0 for M flagged accounts (#23 above). Commands like addip/delip/etc check as well. Now that I think about it they may also screw up and not bypass the check for M flagged accounts either...

Outside of the change commands the site uinfo/ginfo and perhaps a few more really need to be made aware of groupadmin status so as not to reveal private info of other groups as this is what got this whole discussion going...

PROPOSAL:
I'm content to define hardcode 1 and M flagged users as "real" admins and thus they can admin all groups all the time. By default they can change admingroup settings for themselves so it's not like you can stop them! Everybody else MUST have specific groupadmin rights granted and they can only modify or see private info of users in those groups.

I also like the idea of a user who has groupadmin rights being automatically granted the G user flag and having the G flag revoked if no longer the admin of any groups. Therefore an attempt to add G to a user won't actually work, but the G flag will get set once a groupadmin right is defined. G would thus become sort of hardcoded as well. However all tests for admin rights will NOT test for G, but rather the absence of 1/M and/or admingroups. This is probably safer since I'm sure they will sooner or later get set wrong since user files can be manually edited.

The only drawback of this scheme is if in ioFTPD.ini a specific user/group was granted addip rights i.e "addip = G1M =trusted". Assuming a user in the trusted group doesn't have any admin flags (say just the 3 flag or something) and no admingroups are defined that user previously could have added IPs for anyone and now they can't.

The only way around this would be to revert to what we have now. If no admingroups are defined then that implies all groups. I think I'd rather go for the more secure setup and if necessary a script can be used to handle the =trusted type situations, but for the majority of FTP setups no scripts would be required.

11-06-2007, 02:51 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Group rights There are actually 2 more hard coded flags. L - always allow login (M implies L - just learned that!) 1 - inside the add user code M and 1 are tested to determine if the user is a pure admin or a group admin. The G flag isn't hardcoded, it is simply a convention in ioFTPD.ini as neoxed points out. The problem is if you have the G flag but are NOT explicitly the groupadmin of any groups you are sort of considered a regular admin because the User_IsAdmin function allows that. I'm not sure if that is a long standing bug, or a historical artifact... On the other hand if you ARE an admin of specific groups the code ALREADY limits all site change commands to members of those groups. In fact it was so limiting that I had to bypass the check in 6.3.0 for M flagged accounts (#23 above). Commands like addip/delip/etc check as well. Now that I think about it they may also screw up and not bypass the check for M flagged accounts either... Outside of the change commands the site uinfo/ginfo and perhaps a few more really need to be made aware of groupadmin status so as not to reveal private info of other groups as this is what got this whole discussion going... PROPOSAL: I'm content to define hardcode 1 and M flagged users as "real" admins and thus they can admin all groups all the time. By default they can change admingroup settings for themselves so it's not like you can stop them! Everybody else MUST have specific groupadmin rights granted and they can only modify or see private info of users in those groups. I also like the idea of a user who has groupadmin rights being automatically granted the G user flag and having the G flag revoked if no longer the admin of any groups. Therefore an attempt to add G to a user won't actually work, but the G flag will get set once a groupadmin right is defined. G would thus become sort of hardcoded as well. However all tests for admin rights will NOT test for G, but rather the absence of 1/M and/or admingroups. This is probably safer since I'm sure they will sooner or later get set wrong since user files can be manually edited. The only drawback of this scheme is if in ioFTPD.ini a specific user/group was granted addip rights i.e "addip = G1M =trusted". Assuming a user in the trusted group doesn't have any admin flags (say just the 3 flag or something) and no admingroups are defined that user previously could have added IPs for anyone and now they can't. The only way around this would be to revert to what we have now. If no admingroups are defined then that implies all groups. I think I'd rather go for the more secure setup and if necessary a script can be used to handle the =trusted type situations, but for the majority of FTP setups no scripts would be required.