Chris Costello ch...@calldei.com writes:
On Thu, Sep 09, 1999, Narvi wrote:
It sounds like a FreeBSD VM, VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be able to notice) the existence of
others at all.
In Texas we call that a chroot.
ITYM jail(2), which
On Thu, 9 Sep 1999, Daniel O'Connor wrote:
On 09-Sep-99 Jason Young wrote:
After some thought, I think the mount option idea is best. I hadn't
thought of that before. One might want to apply different procfs
security policies to different mounts of procfs, especially in a
jail()
On Thu, 9 Sep 1999, Daniel O'Connor wrote:
On 09-Sep-99 Jason Young wrote:
After some thought, I think the mount option idea is best. I hadn't
thought of that before. One might want to apply different procfs
security policies to different mounts of procfs, especially in a
jail()
On 09-Sep-99 Jason Young wrote:
After some thought, I think the mount option idea is best. I hadn't
thought of that before. One might want to apply different procfs
security policies to different mounts of procfs, especially in a
jail() situation. Good call.
Yeah, you'd have to make
On Thu, 9 Sep 1999, Julian Elischer wrote:
I think he wants something like an "inverted chroot"
(you can see out but others can't see in?
(into all facets, e.g. process stats, etc.)
Then maybe he should begin by looking at the work Poul-Henning has done
on jail(8) code? Is that what you're
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define "see". Access the memory?
On Thu, Sep 09, 1999, Mike Pritchard wrote:
I used to work somewhere where we didn't wany any of the users
to know anything about any other groups of users processes.
We did this by restricting ps to only show other procs that
had the same primary group as the person executing ps.
Root and
* Daniel O'Connor ([EMAIL PROTECTED]) [990909 07:15]:
On 09-Sep-99 Gustavo V G C Rios wrote:
I would not be able to see any other proccess which i am not the
owner, top would indicated, only 8 proccess, for this current scenario.
Linux already have such a facility!
Hack ps and turn off
On Thu, 9 Sep 1999, Julian Elischer wrote:
I think he wants something like an "inverted chroot"
(you can see out but others can't see in?
(into all facets, e.g. process stats, etc.)
It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice
On Thu, Sep 09, 1999, Narvi wrote:
It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be able to notice) the existence of
others at all.
With somedata hiding and given file systems mounted only in such a 'jar'
the ones in it would
-Original Message-
From: owner-freebsd-hack...@freebsd.org
[mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of
Daniel O'Connor
Sent: Wednesday, September 08, 1999 9:05 PM
To: Gustavo V G C Rios
Cc: freebsd-hackers@FreeBSD.ORG; ch...@calldei.com
Subject: Re: CS Project
On 09
On 09-Sep-99 Jason Young wrote:
Hack ps and turn off procfs :)
I would think it more appropriate to adjust procfs' permissions in the
kernel such that a user couldn't look at processes they don't own,
i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read
for wheel or
I think the idea (of a procfs ps) was shot down on the
lists some time
ago because ps needs to retain the ability to look at
the process list
in a kernel coredump. IMHO that's a lot of messy kvm
groveling and
associated kernel-to-userland sync dependencies, just to
cater to the
Some further thoughts before I doze off:
allowed to. This should be controlled by sysctls like
(placement based
on nfs and ffs sysctl placement precedent):
Or even a mount option to procfs :)
After some thought, I think the mount option idea is best. I hadn't
thought of that before.
On 09-Sep-99 Jason Young wrote:
After some thought, I think the mount option idea is best. I hadn't
thought of that before. One might want to apply different procfs
security policies to different mounts of procfs, especially in a
jail() situation. Good call.
Yeah, you'd have to make sure
I think he wants something like an inverted chroot
(you can see out but others can't see in?
(into all facets, e.g. process stats, etc.)
julian
On Wed, 8 Sep 1999, Chuck Robey wrote:
On Wed, 8 Sep 1999, Gustavo V G C Rios wrote:
Dear gentleman,
i am a computer science student, and
On Thu, 9 Sep 1999, Julian Elischer wrote:
I think he wants something like an inverted chroot
(you can see out but others can't see in?
(into all facets, e.g. process stats, etc.)
Then maybe he should begin by looking at the work Poul-Henning has done
on jail(8) code? Is that what you're
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define see. Access the memory?
On Thu, Sep 09, 1999, Mike Pritchard wrote:
I used to work somewhere where we didn't wany any of the users
to know anything about any other groups of users processes.
We did this by restricting ps to only show other procs that
had the same primary group as the person executing ps.
Root and
* Daniel O'Connor (docon...@gsoft.com.au) [990909 07:15]:
On 09-Sep-99 Gustavo V G C Rios wrote:
I would not be able to see any other proccess which i am not the
owner, top would indicated, only 8 proccess, for this current scenario.
Linux already have such a facility!
Hack ps and turn
On Thu, 9 Sep 1999, Julian Elischer wrote:
I think he wants something like an inverted chroot
(you can see out but others can't see in?
(into all facets, e.g. process stats, etc.)
It sounds like a FreeBSD VM, VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be
On Thu, Sep 09, 1999, Narvi wrote:
It sounds like a FreeBSD VM, VM taken to mean virtual machine. Anybody
in such a 'jar' would not notice (be able to notice) the existence of
others at all.
With somedata hiding and given file systems mounted only in such a 'jar'
the ones in it would have
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define "see". Access the memory? See that
Chris Costello wrote:
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define
Gustavo V G C Rios wrote:
After changes made by me:
I would be able to see any other proccess which i am not the owner, top
would not be (there was a mistaken in the sentece above, it was
in lack of "not" )
would indicated, only 8 proccess, for this current
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
I would be able to see any other proccess which i am not the owner, top
would indicated, only 8 proccess, for this current scenario.
do you understand now, what i meant?
Linux already have such a facility!
I don't believe such a facility
On 09-Sep-99 Gustavo V G C Rios wrote:
I would be able to see any other proccess which i am not the owner, top
would not be (there was a mistaken in the sentece above, it was
in lack of "not" )
would indicated, only 8 proccess, for this current scenario.
On 09-Sep-99 Jason Young wrote:
Hack ps and turn off procfs :)
I would think it more appropriate to adjust procfs' permissions in the
kernel such that a user couldn't look at processes they don't own,
i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read
for wheel or
I think the idea (of a procfs ps) was shot down on the
lists some time
ago because ps needs to retain the ability to look at
the process list
in a kernel coredump. IMHO that's a lot of messy kvm
groveling and
associated kernel-to-userland sync dependencies, just to
cater to the
Some further thoughts before I doze off:
allowed to. This should be controlled by sysctls like
(placement based
on nfs and ffs sysctl placement precedent):
Or even a mount option to procfs :)
After some thought, I think the mount option idea is best. I hadn't
thought of that before.
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define see. Access the memory? See that it
Chris Costello wrote:
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
Dear gentleman,
One clear example:
No user(but only that ones previous allowed to) should be able to see
other users process. This facility have to be done at kernel level,
(that's what i think).
Define see.
Gustavo V G C Rios wrote:
After changes made by me:
I would be able to see any other proccess which i am not the owner, top
would not be (there was a mistaken in the sentece above, it was
in lack of not )
would indicated, only 8 proccess, for this current
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote:
I would be able to see any other proccess which i am not the owner, top
would indicated, only 8 proccess, for this current scenario.
do you understand now, what i meant?
Linux already have such a facility!
I don't believe such a facility
On 09-Sep-99 Gustavo V G C Rios wrote:
I would be able to see any other proccess which i am not the owner, top
would not be (there was a mistaken in the sentece above, it was
in lack of not )
would indicated, only 8 proccess, for this current scenario.
On Wed, 8 Sep 1999, Gustavo V G C Rios wrote:
Dear gentleman,
i am a computer science student, and this semester i had to began my
project to get graduated. After looking for some interesting topics on
many sources, one rised up:
Privacity on Shared Environments.
My ideia is to add
36 matches
Mail list logo