On Fri 18 Jun 2010 09:37 +1000, Allan McRae wrote: > On 18/06/10 09:12, Loui Chang wrote: > >On Fri 18 Jun 2010 08:19 +1000, Allan McRae wrote: > >>On 18/06/10 01:09, Loui Chang wrote: > >>>Why not just take sudo and asroot out of the equation and treat makepkg > >>>as a real non-handholding executable? > >> > >>What do you mean? Remove automatic dependency installation or > >>require the entire thin to be run as root? > > > >Enable the entire thing to be run as any user. > > > >A user does not necessarily need to be called 'root' to have package > >manager privileges, nor do they need to be 'root' to have superuser > >privileges, so why do we need a special flag for when the user does > >happen to be 'root'? > > > >I think a user should arrange those himself, rather than having makepkg > >assume that he wants to become root via sudo. If the user hasn't > >previously arranged the privs, then makepkg dependency installation > >should fail. > > > >In my opinion any use of sudo, and any restrictions on root in makepkg > >should be removed. If you're keen to this idea I could provide some > >patches. > > I still am not sure where you are going with this...
What I'm essentially saying is that makepkg shouldn't be the one managing privileges. It should be the users. > 1) pacman requires you to be root to install packages (or at least > UID=0 I think) > > pacman -S pacman > error: you cannot perform this operation unless you are root. > > 2) Doing the actual packaging as root is dangerous, especially if > you have "make install" by accident in your PKGBUILD. Or, as does > happen, the software has a shitty Makefile and ignores DESTDIR for > part of the installation (for this reason --asroot is not being > removed). > > So we have conflicting needs within makepkg. root to install, > non-root to build. When makepkg needs to install dependency > packages, it checks if sudo is an option and if not falls back to > using "su -c", and if that fails it gives up. Are you proposing > that it just gives up straight away and not attempt privilege > escalation? Yes, I am proposing that. You can always drop to more restricted permissions to build if you are a worried superuser. It's an admin's duty to understand these precautions isn't it?
