Re^2: letting a browser client select a file to download by inode

More that passing out arbitrary files by inum could allow people to get access to files that they shouldn't (e.g. if your documents are served from the same filesystem as your Apache configuration someone could figure out the likely inum for httpd.conf; worse if your document root is on the same filesystem as /etc).

Comment on Re^2: letting a browser client select a file to download by inode

Replies are listed 'Best First'.
Re^3: letting a browser client select a file to download by inode by leocharre (Priest) on Dec 27, 2005 at 13:27 UTC
I want to underscore the following: submitting an inode num to the server is not the only requirement to download a file There is already a whole method of identifying the user by ip, auth, session time, etc etc- it does happen in ssl. The validity of your 'pageview' is checked with every action etc.. If one were to try to view or download a file they cannot, they are pooped out. So, first an inode is submitted. Then the inode must be in my valid 'files' table which does not record about anything but .doc, .pdf, etc like "document" files. Second, there is a "files to users" (normalisation) table that simply establishes a relationship between a user and a file. To download a file, you must have an entry in the files to users table. If not, the app freaks the hell out, ends your session, sends a notice for the admin to view the logs.	[reply]

Replies are listed 'Best First'.

Re^3: letting a browser client select a file to download by inode
by leocharre (Priest) on Dec 27, 2005 at 13:27 UTC

I want to underscore the following: submitting an inode num to the server is not the only requirement to download a file

There is already a whole method of identifying the user by ip, auth, session time, etc etc- it does happen in ssl. The validity of your 'pageview' is checked with every action etc.. If one were to try to view or download a file they cannot, they are pooped out.

So, first an inode is submitted. Then the inode *must* be in my valid 'files' table which does *not* record about anything but .doc, .pdf, etc like "document" files.

Second, there is a "files to users" (normalisation) table that simply establishes a relationship between a user and a file. To download a file, you must have an entry in the files to users table. If not, the app freaks the hell out, ends your session, sends a notice for the admin to view the logs.

[reply]