On Thu, 24 Apr 2008 04:45:27 +0200, Hisham <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 22, 2008 at 7:05 AM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >> On 17/04/2008, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >> > On 17/04/2008, Carlo Calica <[EMAIL PROTECTED]> wrote: >> > > On Tue, Apr 15, 2008 at 10:55 PM, Jonas Karlsson >> > > >> > > <[EMAIL PROTECTED]> wrote: >> > > >> > > > Hello, >> > > > >> > > > New major features >> > > > Scripts: >> > > > * "unsudoing" >> >> > > >> > > >> > > There are a number of sudo changes in this release. To use these >> > > properly /Files/Compile should be group sys and permission g+ws. This >> > > is done on 014.01 but it would be nice for these changes to happen on >> > > old installs as well. Unfortunately, Post_Install can't operate >> > > outside of $target/$target_settings. Should there be a check in >> > > bin/Compile? What's the best way? >> > > >> > >> > This is an issue I've thought much about, but haven't found a clean >> solution. >> > If someone can come up with a clean solution, please post it. We need >> it. If >> > no clean solution is found, should we accept a workaround? >> > >> > To recap the problem: >> > Most users have used sudo or root to run Compile. This is discuoraged, >> but >> > there was no clean way to build some recipes without it before this >> release >> > of Compile. Because Compile was run with superuser privileges a lot of >> > entried in /Files/Compile will be owned by that user and various actions >> > executed by normal user (which is the recommended way to run Compile) >> > will fail. We need to prevent that. >> > >> I'm holding the release until this issue is solved. >> But unforunatly I've been swamped with work since the end of last >> week, so I'm uncertain when I will be able to work on a solution. >> >> Michael and I had a discussion about this issue before the weekend >> where we came to the conclussion thath the current implementation with >> "$sudo" (not "$sudo_exec"), which depend on if /Files/Compile is >> writable has to be reworked as it breaks if permissions mismatch for >> directories further down the hierarchy. But we didn't want to make any >> major changes this close to a release. Instead our idea is to >> implement a "backup" sudo call for when an operation fails. Depending >> on where in the hierarchy it should either call 'rm -rf' or 'chgrp >> sys/chmod g+rws'. For example permission errors on >> /Files/Compile/Recipes/Foo/x.y should trigger rm while permission >> errors on /Files/Compile/LocalRecipes should trigger chgrp. A >> recommendation would be to try a simple 'touch' before resource >> consuming actions (that might fail) like Unpack_Archive. >> >> I don't know when I will be able to work on this and Michael said that >> he wont be able to work on this in the close future, so this is a >> request for anyone that has the oportunity to at least take a look at >> it. > > In my machine at least, I just did a: > > cd /Files/Compile > chown -R hisham:users * > > Has it been considered to advise users to do that when they upgrade > instead of littering the code with lots of checks? > Yes, I've thought of that, but this will fail on multiple user systems. If Jim tries to build while Joe owns the files it will fail. -- /Jonas > trying to teach my fingers not to type "sudo Compile" anymore :) You can still type it, but it will have no effect anymore (beyond moving the sudo authentication to right after you issue the command). _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
