| 1 |
Peter Hjalmarsson posted on Fri, 11 Dec 2009 23:46:07 +0100 as excerpted: |
| 2 |
|
| 3 |
> fre 2009-12-11 klockan 12:11 -0800 skrev Zac Medico: |
| 4 |
>> Should we enable FEATURES=userpriv by default? If we do that then do we |
| 5 |
>> also need to support RESTRICT=userpriv? Maybe RESTRICT=userpriv should |
| 6 |
>> not be supported on the grounds that it is never justified? What about |
| 7 |
>> prefix support (in EAPI 3), which often doesn't have root privileges? |
| 8 |
> |
| 9 |
> That would be problematic for hardened, as they set the permission for |
| 10 |
> /usr/src/* to root only. |
| 11 |
|
| 12 |
Wouldn't setting it as its own user, say kernelcomp, and su/sudoing to |
| 13 |
that before dealing with the kernel sources, be better? Kernel docs have |
| 14 |
long said don't compile sources as root, tho obviously for installing |
| 15 |
them you normally need to be root. |
| 16 |
|
| 17 |
FWIW, my (non-gentoo-related) kernel scripts use a non-root user, tho |
| 18 |
it's my normal admin user (not my user user) that has blanket sudo |
| 19 |
without password permission, but it could be a dedicated one just as |
| 20 |
easily. I'd expect hardened to be even more particular about compiling |
| 21 |
as root, tho I see why general access isn't allowed. But dedicated user |
| 22 |
seems good. |
| 23 |
|
| 24 |
Even if that's done, however, it'll take some time to update and test. |
| 25 |
But it could be made the default before that, and hardened could set its |
| 26 |
own default elsewise. |
| 27 |
|
| 28 |
-- |
| 29 |
Duncan - List replies preferred. No HTML msgs. |
| 30 |
"Every nonfree program has a lord, a master -- |
| 31 |
and if you use the program, he is your master." Richard Stallman |
Archives