in reply to Re: cleaning up absolute path without resolving symlinks
in thread cleaning up absolute path without resolving symlinks

My application serves files to users via a web interface.

When a user is authenticated, the application instance has to be confined to the user's assigned parts of the filesystem hierarchy.

First there is the hierarchy of what the application can access, say, '/serve/files'.

Then there is the hierarchy (filesystem tree slice(?)) That user x is given access to; '/serve/files/a' and '/serve/files/b'.

When the application asks to do something to /serve/files/g, it should recognize that this is not one of the places that the current instance of this application (the user) can access.

The ammount of data is large and I foresee it getting much larger. So, mounting will happen.

I need to know that file /serve/files/a/this is first and foremost within '/serve/files'. But /serve/files/a might someday be mounted, as may serve/files/b and serve/files/c, and from different drives.

(I have fantasized about just making each 'user' a real user on the system (linux) and taking it from there. Which seems sensible to me- but freaks out my co-workers. It's been pretty much decided that it would be too.. iffy? complex? Or leave too many security holes open; to do that. So I have to mimic a filesystem, somewhat.)

  • Comment on Re^2: cleaning up absolute path without resolving symlinks

Replies are listed 'Best First'.
Re^3: cleaning up absolute path without resolving symlinks
by agianni (Hermit) on Mar 06, 2007 at 20:00 UTC
    I'm not seeing where the symlinks fit in. Mounting separate volumes should be transparent to file system users like your application, shouldn't they? i.e. if you mount /serve/files/b from a remote disk, shouldn't it still just look like /serve/files/b, no symlink involved? Or are you implying a symlink somewhere else?

      Here's how it fits in.

      On your shell.. Imagine you are user 'bubba'..

      mkdir /home/bubba/served
      mkdir /etc/a
      touch /etc/a/filehere
      ln -s /etc/a /home/bubba/served/a
      

      Now for perl..

      #!/usr/bin/perl -w use Cwd; use strict; for (qw( /home/bubba/served /home/bubba/served/a /home/bubba/served/a/filehere )){ printf "$_ = %s\n",Cwd::abs_path($_); }

      You get

      bubba#mescaline# perl script.pl
      /home/bubba/served = /home/bubba/served
      /home/bubba/served/a = /etc/a
      /home/bubba/served/a/filehere = /etc/a/filehere
      

      I don't know if people using this in the future will be mounting directly to /home/bubba/served , in fact, I'm pretty sure they will not. Things will be mounted somewhere and likely symlinked to /home/bubba/served. ( I believe hard links don't work accross filesystems.. haha).

      What the program needs to verify is that whatever the file is, it is 'within' the hierarchy of /home/bubba/served. This is why resolving symlinks won't cut it.