| 1 |
"Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted |
| 2 |
200610281108.21396.volker.armin.hemmann@××××××××××××.de, excerpted below, |
| 3 |
on Sat, 28 Oct 2006 11:08:21 +0200: |
| 4 |
|
| 5 |
> On Saturday 28 October 2006 07:02, Duncan wrote: |
| 6 |
> |
| 7 |
>> You /could/ try turning sandbox off (in FEATURES). That's a bit |
| 8 |
>> dangerous by itself, but if you turn userpriv on at the same time, it |
| 9 |
>> should be fairly safe. |
| 10 |
> |
| 11 |
> NO! |
| 12 |
> |
| 13 |
> Just no! |
| 14 |
> |
| 15 |
> Never ever turn of sandbox. Without sandbox, files can end everywhere in |
| 16 |
> your installation, destroying stuff, make apps segfault randomly - and the |
| 17 |
> worst, portage does not know about them. |
| 18 |
> |
| 19 |
> Never ever turn of sandbox. And never tell others to do so. btw |
| 20 |
|
| 21 |
Wow, and I thought /I/ was a bit strict on that! FWIW, you are right, to |
| 22 |
a point. Sandbox is there as a protection measure and turning it off can |
| 23 |
be dangerous, as I said. However, it's /not/ the end of the world! |
| 24 |
Ebuilds can and routinely do turn it off or tell it to ignore specific |
| 25 |
parts of the filesystem when it gets in the way of what the build needs to |
| 26 |
do. Sandbox is just there to keep the unexpected from happening. |
| 27 |
|
| 28 |
Anyway, userpriv works quite well too, as it should, because it uses the |
| 29 |
same user and group file protection Unix systems have historically used. |
| 30 |
If the ebuild in userpriv mode can delete system files or otherwise screw |
| 31 |
up the system, something's wrong and the system is in pretty bad shape |
| 32 |
security-wise already, because regular users SHOULDN'T be able to mess |
| 33 |
with the system, or with other user's files, unless the other user set it |
| 34 |
up specifically to allow that. |
| 35 |
|
| 36 |
The real danger therefore is turning BOTH userpriv and sandbox off, which |
| 37 |
is why I said I couldn't recommend it, and stressed making sure things |
| 38 |
were backed up if one tried. Even then, it's something devs routinely say |
| 39 |
to do, hopefully after they've taken a look at the sandbox violation log |
| 40 |
and verified it's not going to do anything stupid. |
| 41 |
|
| 42 |
I also said it shouldn't be a sandbox problem (everybody has it enabled |
| 43 |
unless they've turned it off deliberately, as it's on by default, and the |
| 44 |
fact that others have gcc installed and it's not a widely known issue |
| 45 |
means it's not a normal sandbox problem), but that IS the obvious direct |
| 46 |
issue in this case, or there'd not be that violation log. I ALSO said |
| 47 |
it's risky to turn off, particularly as the file it's trying to access |
| 48 |
doesn't belong to the package in question (gcc) but rather to a different |
| 49 |
vital system package, glibc. However, as long as userpriv is on, it's not |
| 50 |
an undue risk, and if damage occurs, there are bigger problems to worry |
| 51 |
about. |
| 52 |
|
| 53 |
So anyway, calm down. userpriv is exactly the same level of system |
| 54 |
protection normally in place, so as long as it's on, there shouldn't be |
| 55 |
any real risk. Only when BOTH userpriv and sandbox are off, is there a |
| 56 |
serious risk, and I specifically said I did NOT recommend that, at least |
| 57 |
until a dev takes a look at it and says go ahead. |
| 58 |
|
| 59 |
-- |
| 60 |
Duncan - List replies preferred. No HTML msgs. |
| 61 |
"Every nonfree program has a lord, a master -- |
| 62 |
and if you use the program, he is your master." Richard Stallman |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-amd64@g.o mailing list |
Archives