Yil
04-02-2007, 12:29 AM
I've been chatting about File Contexts with tuff and instead of replying via another PM I thought I should mention something about them here since I didn't understand their usage until I looked at the code and though others might find this useful.
First off what is a File Context? Basically this is how ioFTPD handles extra data stored in the .ioFTPD file that is associated with a file or the directory. It is accessible via itcl using the "vfs chattr" command as I documented in the itcl reference.
vfs Chattr <directory/file> <0> : Returns PRIVATE setting
vfs Chattr <directory/file> <0> <value> : Sets PRIVATE setting
vfs Chattr <directory/file> <1> : Returns SYMBOLIC LINK target
vfs Chattr <directory/file> <1> <target> : Creates SYMBOLIC LINK
Currently ioFTPD only examines the symbolic link field for directories so while you can set it for a file it won't mean anything.
The private setting is actually for fine grained file/directory access control. Basically this allows you to specify a permission type field like in ioFTPD.ini (-username =groupname !*) which overrides the default user/group rwx flags. Pretty cool huh?
The interface however was never well documented and scripters noticed (?) that you weren't limited to specifying just 0 or 1 but actually had 0-255 as a valid range. I'm not advocating using the .ioFTPD.ini file to store extra data because the server is forced to parse and keep writing it out on every directory change event, but it is useful.
One thing our discussion was touching on was how using chattr was safe because by going through ioFTPD you implicitly have a lock that synchronizes access to this extra data and you don't have to worry about cleaning anything up if the file is deleted. You can achieve all but the auto-delete bit though by use the various waitobject functions. Since the waitobjects take a name for the lock you can just use the name of the file you want to lock and you can then synchronize events yourself.
There was one other benefit I'm not sure of. I thought renaming/moving a file kept it's file context which is sorta cool. I think however this just works for .ioFTPD* files. I suppose I could make it re-apply the setting though.
If you use this stuff, please chime in and tell me how and what your doing with it...
First off what is a File Context? Basically this is how ioFTPD handles extra data stored in the .ioFTPD file that is associated with a file or the directory. It is accessible via itcl using the "vfs chattr" command as I documented in the itcl reference.
vfs Chattr <directory/file> <0> : Returns PRIVATE setting
vfs Chattr <directory/file> <0> <value> : Sets PRIVATE setting
vfs Chattr <directory/file> <1> : Returns SYMBOLIC LINK target
vfs Chattr <directory/file> <1> <target> : Creates SYMBOLIC LINK
Currently ioFTPD only examines the symbolic link field for directories so while you can set it for a file it won't mean anything.
The private setting is actually for fine grained file/directory access control. Basically this allows you to specify a permission type field like in ioFTPD.ini (-username =groupname !*) which overrides the default user/group rwx flags. Pretty cool huh?
The interface however was never well documented and scripters noticed (?) that you weren't limited to specifying just 0 or 1 but actually had 0-255 as a valid range. I'm not advocating using the .ioFTPD.ini file to store extra data because the server is forced to parse and keep writing it out on every directory change event, but it is useful.
One thing our discussion was touching on was how using chattr was safe because by going through ioFTPD you implicitly have a lock that synchronizes access to this extra data and you don't have to worry about cleaning anything up if the file is deleted. You can achieve all but the auto-delete bit though by use the various waitobject functions. Since the waitobjects take a name for the lock you can just use the name of the file you want to lock and you can then synchronize events yourself.
There was one other benefit I'm not sure of. I thought renaming/moving a file kept it's file context which is sorta cool. I think however this just works for .ioFTPD* files. I suppose I could make it re-apply the setting though.
If you use this stuff, please chime in and tell me how and what your doing with it...