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

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.

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

Replies are listed 'Best First'.
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]