Xen, UML, VM, VMware, separate computers
http://linux-vserver.org/ would also seem to be an excellent match.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
(snipped the CC list - hope that's ok)
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
NACK, the admin (and with
Albert Cahalan wrote:
Note that the admin hopefully does not normally run as root.
The admin should be using a normal user account most of the
time, to reduce the damage caused by his accidents.
Openwall and GrSecurity solved this by having a special group that can
see everything, just like root.
(snipped the CC list - hope that's ok)
No - it's not ok.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line
On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
(snipped the CC list - hope that's ok)
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
This really isn't about security.
Information
(refiled the CC list)
On Tue, 15 Mar 2005, Albert Cahalan wrote:
On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
This really isn't about
Albert Cahalan wrote:
This really isn't about security. Privacy may be undesirable.
I agree, privacy is not security. My patch tries to enhance privacy
without giving up security.
You think losing the social pressure that comes with mutual surveillance
results in loss of security, I don't.
On Mar 15, 2005, at 16:18, Rene Scharfe wrote:
It's easily visible in the style of public toilets: in some contries
you have one big room with no walls in between where all men or women
merrily shit together, in other countries (like mine) every person can
lock himself into a private closet.
Albert Cahalan wrote:
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes'
/proc directories? Isn't it similar to being able to chmod their home
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes'
/proc
Hi!
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes'
/proc directories? Isn't it similar to being able to chmod their home
directories? They
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
Why do you think users should not be allowed to chmod their processes'
/proc directories? Isn't it similar to being able to chmod their home
directories? They own
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
Why do you think users should not be allowed to chmod their processes'
/proc directories? Isn't it similar
OK, folks, another try to enhance privacy by hiding
process details from other users. Why not simply use
chmod to set the permissions of /proc/pid directories?
This patch implements it.
Children processes inherit their parents' proc
permissions on fork. You can only set (and remove)
read
14 matches
Mail list logo
