On Tue, May 03, 2005 at 10:09:14AM -0500, Aaron Griffin wrote: > Ok, in response to alot of the different ideas raised here: > > a) someone mentioned that there's no way to protect a user from > running a PKGBUILD which does "rm -rf /"... well, by the same notion, > there's no way to prevent a user from downloading a shell script which > simply does: > $ echo "enter the root password to install good stuff!" > $ su -c "rm -rf /" > it's all about caution and intelligence - though it'd be great for > everyone to be protected from themselves, it just wont happen... > there's wiki links to scripts that say "download this, chmod it, and > run it" - I can go change one of those links to the snippet mentioned > above, and careless users will run it... there's no "ultimate safety"
This is true, but the question is how easy you make it for this sort of
thing to happen. It's one thing to say download this, then run it.
Someone can look at it. But if I'm running srcpac and I accidently install
xorg-reallybreaksmycomputer (from unsupported) instead of xorg, I had no
idea.
It's not about stopping stupid users from doing stupid things, it's about
how much you trust. The less automatic and "hidden" the process is, the
less likely things will go unnoticed.
> b) srcpac must run as root... I didn't know this... the following
> could be a minor fix (off the top of my head):
> function do_pacman()
> {
> echo "the root password is required to continue:"
> su -c "pacman $@"
> }
> sed -i "[EMAIL PROTECTED]@[EMAIL PROTECTED]" /usr/bin/srcpac
>
> with that in place, srcpac can build with fakeroot...protecting
> against malicious PKGBUILDs, but that still wouldn't prevent bad
> install scripts (shouldn't pacman validate this anyway, for security
> purposes?)
It's not pacman that needs to run as root. If I'm installing package x,
which needs package y installed, how can makepkg build and install y before
building x, if it's not being run as root?
The other thing is, how can it put packages in /var/cache/pacman/pkg? I've
already suggested a fix for this part.
> c) why not just make a custom srcpac incarnation... srcpac-aur which
> has a whole mess of "security" fixes?
Didn't I say that already? But again, you'll be reimplementing a bunch of
the pacman package upgrade logic. It'll also be really slow.
> d) when the AUR was being built, I was kind of expecting it to do some
> sort of validation... right now it seems more like a formatted file
> upload... yeah it makes sure the PKGBUILDs are valid and all that, but
> I was expecting a bit more (perhaps a trial build on the AUR server?)
> in terms of "keeping things sane"...
Are you willing to donate your machine so I can blow it up? Didn't think
so...
We could use a chroot jail, but again that's a lot more work and it isn't
going on dragon (archlinux.org). We'd need a second remote build
machine... which is starting to sound a lot like pacbuild again...
That also means that your package could potentially take hours to be
"validated". Especially because building in something like a UML instance
is significantly slower.
Jason
--
If you understand, things are just as they are. If you do not understand,
things are just as they are.
pgpormwdXpWjQ.pgp
Description: PGP signature
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
