Ken, * Ken Tanzer ([email protected]) wrote: > I could be way off base, but it seems like the exposure is limited. > Sure, each user can access their database, providing they can > authenticate successfully. (Of course, I don't care what they do with > their database.) This essentially results in a bunch of limited > exposures of individual DBs, which seems somehow different than one > point of access that can access multiple databases, including > potentially ones I do care about. I have a lot of faith that a Postgres > user won't be able to do anything other than access their own database.
You realize that some information (like roles/users) is shared
cluster-wide and isn't limited to a specific database, right? That's
usually where web-hosting folks trip up first..
> If I understand your comment correctly, that would be suggesting that I
> have already exposed all the databases, because you could ssh in with my
> credentials and do all kinds of root stuff.
Giving users a shell doesn't mean you've given them access to all
databases or 'root stuff' at all. I can understand not wanting to give
users a shell on your database server, but it certainly wouldn't be the
same as giving them root on it.
>> How are you going to let them edit the PHP files, or read the log file,
>> if all they can get to is psql?
> Well now that's a great question. I had thought I was going to have
> people use sftp/scp, but I can see that apparently doesn't work without
> a more "normal" shell than psql. (Although maybe you could build that
> support in? ;) )
Erm, I don't believe you need a real shell to allow them sftp.. You
just have to set things up correctly.
> So I guess my other option is to use one of these web-based server side
> file managers, and lock the top level at the user's home directory.
> (There seem to be lots of them out there--would anyone suggest a good
> one that allows upload/editing?? ) I can see this would need to be
> user/password authenticated, and to respect the permissions/run as each
> individual user.
Yeah, that's a bit far afield from the purpose of this list...
>> You could always build your own lobotomized version of psql. I think
>> though that (a) this is not likely to close all the holes and (b) the
>> whole concept needs rethinking anyway. psql is *meant* to be executed
>> on the client side. You're trying to put the firewall in the wrong
>> place, and what you're mainly going to accomplish is annoy your users.
>> You will for example be making it awfully difficult for them to use
>> \copy, \i, \e, \g, the list goes on.
> I'm not really eager to go down this path, but nonetheless it's not
> obvious to me why giving psql a lobotomy (or hopefully a careful
> surgical tweak) to disable the "\!" functionality would impact all those
> other functions.
Have you looked at what those functions are..? \copy is used to copy a
file on the filesystem into the database; \i allows a user to run SQL
commands from a file on the filesystem, etc, etc. If you're ok with
them having access to the filesystem, what is the issue with giving them
a shell? I'm sure you'd want to lock it down some, but that shouldn't
be all that difficult to do..
Thanks,
Stephen
signature.asc
Description: Digital signature
