On Sunday 14 January 2007 18:46, Chris Gianelloni wrote:
> On Fri, 2007-01-12 at 22:46 +, Stephen Bennett wrote:
> > On Fri, 12 Jan 2007 19:36:06 +
> >
> > Tristan Heaven <[EMAIL PROTECTED]> wrote:
> > > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> > > They have to be able to
On Friday 12 January 2007 22:35, Chris Gianelloni wrote:
> It has nothing to do with the sandbox. It's because /usr/games/lib
> isn't readable to people outside the "games" group.
Isn't that a rather silly restriction. What is there in /usr/games/lib that
may not be seen by people outside the gr
On Fri, 2007-01-12 at 22:46 +, Stephen Bennett wrote:
> On Fri, 12 Jan 2007 19:36:06 +
> Tristan Heaven <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> > They have to be able to read /usr/games/lib.
>
> In which case adding the portage user to
maillog: 12/01/2007-15:08:15(-0800): Robin H. Johnson types
>
> The vpopmail stuff has/has a similar issue (upstream is working on
> solving it via a different avenue at which point the problem will go
> away).
But I tried "emerge vpopmail" on a clean system... the /var/vpopmail/lib and
include
On Fri, 12 Jan 2007 15:08:15 -0800
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> Putting the portage user into the special group would mean that
> somebody could steal the MySQL password - so do you
> RESTRICT=userpriv, or fail the build?
If someone can subvert Portage's build process they can
On Fri, Jan 12, 2007 at 10:46:36PM +, Stephen Bennett wrote:
> > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> > They have to be able to read /usr/games/lib.
> In which case adding the portage user to the games group seems overall
> to be a better solution than requiring root priv
On Fri, 12 Jan 2007 19:36:06 +
Tristan Heaven <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> They have to be able to read /usr/games/lib.
In which case adding the portage user to the games group seems overall
to be a better solution than requiring roo
On Fri, 2007-01-12 at 13:05 -0800, Drake Wyrm wrote:
> Tristan Heaven <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> > > # These are games... no idea why, input appreciated
> > > games-board/ggz-txt-client
> > > games-board/ggz-sdl-games
> > > games-board
Tristan Heaven <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> > # These are games... no idea why, input appreciated
> > games-board/ggz-txt-client
> > games-board/ggz-sdl-games
> > games-board/ggz-gtk-games
> > games-board/ggz-kde-games
> > games-board/gnuc
On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> # These are games... no idea why, input appreciated
> games-board/ggz-txt-client
> games-board/ggz-sdl-games
> games-board/ggz-gtk-games
> games-board/ggz-kde-games
> games-board/gnuchess-book
> games-board/ggz-kde-client
> games-board/ggz
On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote:
> # no idea about the following three, input appreciated
> app-admin/gps
> media-gfx/maya
This one doesn't need RESTRICT=userpriv (at least my 8.0 ebuild in my
overlay doesn't) from my testing.
> # These are games... no idea why, input app
On Sat, Jan 13, 2007 at 12:53:35AM +0900, Georgi Georgiev wrote:
> RESTRICT=userpriv or RESTRICT=nouserpriv (no idea why there are both).
no.* is the old form for restricts; the 'no' chunk of it when seen,
should be removed.
~harring
pgpieaR6Z50In.pgp
Description: PGP signature
Ciaran pointed out that there are "a small number of occasions where it
[the userpriv FEATURE] really does need to be disabled". I consequently
decided to see what these legitimate reasons are but it appears that
RESTRICT=userpriv is not needed in a lot of cases.
Here is a list of all packages tha
13 matches
Mail list logo
