Re^2: can a perl script act as a daemon to serve data in its symbol table?

the more i think about it.. yes.. you're right and i feel like a dummy about it. .i *am* trying to recreate a filesystem! This whole thing lead me to get into filesystem design.. shucks, you'd imagine that would be enought to say 'hey, what the f**ck do you think you're doing!"

Initially I was considering simply using the filesystem- gids, actualy accounts on the box (linux), etc . They could log in via a web interface, ftp, whatever. Thing is, this idea freaked out my sysadmin. There will be anything from hundreds to thousands of users per implementation (yes this will be opensourced, thus grinded, remade, and cleansed by the hands of.. uh.. ) -

This system will serve sensitive data. Having this layer of abstraction pretty much posing as a filesystem, would help that tainted data is of the least sensitive nature...

To tell the server what file they want to see info on, the tainted data is just an id for a file. The number itself means nothing to the os. It's not a path, not an inode, etc.

The idea to further the app before optimizing is very helpful, thank you so much. it makes sense to me. it really helped me from going insane. further, that is.

Comment on Re^2: can a perl script act as a daemon to serve data in its symbol table?

Replies are listed 'Best First'.
Re^3: can a perl script act as a daemon to serve data in its symbol table? by tirwhan (Abbot) on Feb 02, 2006 at 08:53 UTC
Don't worry, we've all been there :-). But if you're recreating a filesystem, a better solution may be to use the existing one. As I understand your post, you will now be limiting access to the files to be only via the webserver, right? So you don't have to worry about access at the filesystem level, you just need to make it simple enough for your web server to only ever serve the correct files to the client (this does break down if someone manages to compromise your webserver, but that's a hard problem to solve). So when a user logs in, get the access data for that user from the database and create a new directory in the webtree containing sym- or hard links to the files that he has access rights to. Have the server only serve files for that user from this directory and delete it after the user logs out. This solution may not be so good if you've got umpteen-thousand files you're serving to each user, but otherwise it seems like the simplest and most efficient solution to your requirements. There are ten types of people: those that understand binary and those that don't.	[reply] [d/l]
Re^4: can a perl script act as a daemon to serve data in its symbol table? by leocharre (Priest) on Feb 02, 2006 at 17:53 UTC
ooh.. that's pretty wild.. hmm... so for each user.. if they get access to say.. this/path/over/here , make a soft link to that in say... username/here .. oooh.... im getting goosebumps.. that's such a *ix dirty sex trick...	[reply]
Re^5: can a perl script act as a daemon to serve data in its symbol table? by tirwhan (Abbot) on Feb 02, 2006 at 18:15 UTC
:-). It's not that smutty, actually shows how powerful the NIX file model is. Anyway, the crucial thing about this is that you have an app (the web server) that still regulates access to the files, because the filesystem permissions are useless for that (the user needs permissions to access to the original file in order to access the link). Well, you can do really dirty tricks with directory permissions but that gets no fun really quickly. BTW, you may want to use hard instead of soft links for files, because You can move the original file around without invalidating the link Deleting the original still leaves your user with access to the linked file, which can be reaped once his directory gets removed again. With hardlinks, an "rm" doesn't remove the file, it just removes one directory entry that points to it (of course, depending on your spec this may actually be a reason for you to go with soft links). Dogma is stupid.*	[reply] [d/l]