1 |
Sebastian Beßler posted on Tue, 16 Mar 2010 13:27:46 +0100 as excerpted: |
2 |
|
3 |
> That is not really a solution, because all it need to be root again is a |
4 |
> simple exit. And chroot-root can break out of the chroot without |
5 |
> problem. |
6 |
|
7 |
See the chroot --userspec option in its manpage... |
8 |
|
9 |
> And you still need to be root to enter the chroot so you must always |
10 |
> type in your root password to start a simple app, even if you drop root |
11 |
> inside the chroot. |
12 |
|
13 |
Not if you have sudo configured properly. Then the user uses their normal |
14 |
password, or none, if sudo is set for no password verification for that |
15 |
command. And since sudo is configurable per command including the passed |
16 |
parameters, it's possible to specifically allow only the single command |
17 |
|
18 |
"sudo linux32 chroot --userspec=xxx:yyy /mnt/point /bin/bash" |
19 |
|
20 |
... and to configure it to require, or not require, entering the user |
21 |
password, as desired. (FWIW, sudo can also be configured to require the |
22 |
changed /to/ user's password, instead of the changed /from/ user's |
23 |
password, so to require root's password here since it's root we're |
24 |
changing to, to do the chroot, but that's a global setting that would |
25 |
apply to all sudo usage on the system, while the require a password or not |
26 |
setting is per configured allowed command or group of commands.) |
27 |
|
28 |
> So this is nothing more then a really fragile hack, to me at last. |
29 |
|
30 |
I won't argue that it's not a hack, but it isn't really more so, or more |
31 |
fragile, IMO, than the whole multilib thing. And it does keep the 32-bit |
32 |
and 64-bit sides better separated. So pick your hack. =:^) |
33 |
|
34 |
-- |
35 |
Duncan - List replies preferred. No HTML msgs. |
36 |
"Every nonfree program has a lord, a master -- |
37 |
and if you use the program, he is your master." Richard Stallman |