On Saturday 28 June 2008 07:22:10 Hisham Muhammad wrote: > On Mon, Jun 23, 2008 at 6:52 AM, Michael Homer <[EMAIL PROTECTED]> wrote: > > On Monday 23 June 2008 21:43:35 MJ Ray wrote: > >> "Carlo Calica" <[EMAIL PROTECTED]> wrote: > >> > This email is to kick off development of the 015 LiveCD. We've been > >> > waiting for GCC 4.3.1 to ship and that has happened now. I know that > >> > Jonas has built a toolchain and some packages. What else is needed to > >> > fill out ChrootCompile? Lucas, could you chime in? Once > >> > ChrootCompile is setup we can start building packages. > >> > >> 2. reduce the amount of sudo'ing that Compile does - if I do this in a > >> cleaner way than my current local changes, will the patch be accepted? > > > > Yes. > > > >> There were comments in #gobolinux that people like Compile sudo'ing > >> because it means you don't have to spot the Password: prompt at > >> install time - but then why not run sudo Compile anyway? > > > > sudo Compile doesn't do anything; all scripts release sudo if started > > with it. > > I've always been uneasy with this feature. I had a lengthy and > fruitful discussion with Jonas about it, and he asked me to bring up > my views on the list. > > As he explained it to me, the motivation for the change was that > sudoed apps would write files owned by superuser in SUDO_USER's home, > which would cause permission problems for the user later. The sudoed > apps in case are basically Scripts and Compile citizens, writing stuff > such as package/recipe list caches and the like. > > I don't think the solution employed was ideal (as seen by the > disruption it caused). I don't remember any other programs that, when > run as root, attempt backing out to a "former user". I know programs > that drop privileges to run as 'nobody' or as a special user, but > that's different. The initial draft was [ "$SUDO_USER" ] && Die "$0 should not be run #0.". Backing it out to the calling user was more of a muscle-memory compromise. > The solution I propose would be to change those scripts so that they > no longer write local state in $HOME (and use somewhere like > /System/Variable instead, when run as superuser). This would avoid > confusion with the $HOME variable and make things much more > predictable. As far as I can tell, this would be basically equivalent (in function, not implementation) to changing the unsudo code to: [ "$SUDO_USER" ] && export HOME=/System/Variable/tmp/Scripts-$SUDO_USER Is that correct? That seems ok to me. > Like Jonas pointed out, even if the "unsudoing feature" is rolled > back, many of the associated changes improve the support for Compile > being run as a regular user. So, I'd say it was a valid and useful > experiment, but I'd rather have "sudo Compile" behave in its former, > intuitive way, and leaving the decision of whether users want to run > Compile as root or not to themselves. So the hooks would still be explicitly run sudo (if EUID!=0)? Or do we have to scatter $sudo_execs through them again?
To be honest, I still don't really see when `sudo Compile` would ever be useful, other than as a workaround for broken recipe behaviour, but people seem to see some utility in it so supporting it is fine. -Michael
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
