How can you deny bash system access when sourcing a file?

Question

I'm having another one of my "Linux noob" moments. This is probably easy to answer for the experienced bashers here.
I need a bash function to extract data from a PKGBUILD for use in other scripts. I want to write it in such a way that there is no significant risk when checking PKGBUILDs from possibly untrusted sources. It would be unreasonable to request the user to manually inspect every PKGBUILD when only extracting information (i.e. not building the package) and when dealing with many PKGBUILDs.
The function itself is very simple in the unsafe version:
for ARG in $@; do
source "$ARG"
echo "$pkgname $pkgver $pkgrel"
done
The reason that I want to source the file is to catch variable changes within the script (obviously missing the build function, but there are some that change outside of it). Parsing the file externally is likely to miss some changes.
How can I safely source the PKGBUILD? Ideally I want to completely limit access to the system, specifically the users home directory. Is there a way to do this as a user without write permissions? Is this what the "nobody" user is for?
I've considered using chroot but that appears to need root privileges. I want to avoid sudo.
Thanks.
Last edited by Xyne (2009-05-19 11:09:25)

Answer 1

Well, unsetting the PATH seems a good idea, but what if the pkgbuild contains sth like this:
pkgver=$(uname -r)
or any similar manner of dynamically generating one of the variables Xyne's interested in by using a command in a subshell? While the following works (i.e. fails as it should):
~$> OLDPATH=$PATH;export PATH="";/bin/bash -r -c 'foo=$(rm foo);foo=$(/bin/rm foo)';export PATH=$OLDPATH
/bin/bash: rm: No such file or directory
/bin/bash: /bin/rm: restricted: cannot specify `/' in command names
any legitimate use of command substitution will fail as well. Not to mention redirection, which is disabled in a restricted shell as well.
And yes, disabling (possibly) malicious bash builtins may be done as well, but it will fail as well if they are used in a legitimate way.
Using "nobody" also relies on the assumption that the user's files aren't world-writable. I think the only safe solution is using a chroot after all, but maybe I'm missing something here.