Chris Costello 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 is only a
Chris Costello <[EMAIL PROTECTED]> 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
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
> >
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
> >
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 woul
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 notic
* 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
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 an
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 wou
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 noti
* 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
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 a
> 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
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
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'r
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 studen
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 s
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 stude
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 befo
> > 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
> cate
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
> -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
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
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 bef
> > 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
> cat
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 o
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Daniel O'Connor
> Sent: Wednesday, September 08, 1999 9:05 PM
> To: Gustavo V G C Rios
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: CS Project
>
>
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 a
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 scen
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 faci
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 curre
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).
>
>
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 t
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
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 sce
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 fac
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 curr
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).
>
>
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
40 matches
Mail list logo
