On Mon, 16 Aug 1999, Mike Smith wrote:
> > But I can't get anyone interested :-(
> Uh, we're all interested; where's the code?
v9fs is the first piece. The servers are done. But I'm mostly out of the
freebsd hacking business at this point (except for maybe via drivers) so I
need some help to get
>
> On Mon, 16 Aug 1999, Terry Lambert wrote:
> > The concept of private namespaces does not exist on FreeBSD.
> > It would require a modification of the lookup mechanism, and,
> > potentially, a seperation of credentials from the process into
> > a session manager.
>
> Yeah but you can fake it p
On Mon, 16 Aug 1999, Terry Lambert wrote:
> The concept of private namespaces does not exist on FreeBSD.
> It would require a modification of the lookup mechanism, and,
> potentially, a seperation of credentials from the process into
> a session manager.
Yeah but you can fake it pretty well witho
On Mon, 16 Aug 1999, Mike Smith wrote:
> > But I can't get anyone interested :-(
> Uh, we're all interested; where's the code?
v9fs is the first piece. The servers are done. But I'm mostly out of the
freebsd hacking business at this point (except for maybe via drivers) so I
need some help to ge
>
> On Mon, 16 Aug 1999, Terry Lambert wrote:
> > The concept of private namespaces does not exist on FreeBSD.
> > It would require a modification of the lookup mechanism, and,
> > potentially, a seperation of credentials from the process into
> > a session manager.
>
> Yeah but you can fake it
On Mon, 16 Aug 1999, Terry Lambert wrote:
> The concept of private namespaces does not exist on FreeBSD.
> It would require a modification of the lookup mechanism, and,
> potentially, a seperation of credentials from the process into
> a session manager.
Yeah but you can fake it pretty well with
On Mon, Aug 16, 1999 at 08:22:02PM +, Terry Lambert wrote:
> This is actually the problem at issue in an SMBFS implementation,
> and for which the Linux guys punted: the credential in SMB is
> per connection, not per user.
Per connection creds suck performance wise (=I haven't seen an implemen
> Actually, i'd expect far fewer problems for the private mounts than for
> user mounts which modify the name space for all processes ...
The concept of private namespaces does not exist on FreeBSD.
It would require a modification of the lookup mechanism, and,
potentially, a seperation of credent
On Mon, Aug 16, 1999 at 08:22:02PM +, Terry Lambert wrote:
> This is actually the problem at issue in an SMBFS implementation,
> and for which the Linux guys punted: the credential in SMB is
> per connection, not per user.
Per connection creds suck performance wise (=I haven't seen an impleme
> Actually, i'd expect far fewer problems for the private mounts than for
> user mounts which modify the name space for all processes ...
The concept of private namespaces does not exist on FreeBSD.
It would require a modification of the lookup mechanism, and,
potentially, a seperation of creden
On Sun, 25 Jul 1999, Brian F. Feldman wrote:
> On Sun, 25 Jul 1999, Mark Newton wrote:
>
> > Ronald G. Minnich wrote:
> > > But thanks for the note. I just now realized that if I add a private name
> > > space to v9fs (which is easy), and then turn on user mounts, user
> > > processes can ha
On Sun, 25 Jul 1999, Mark Newton wrote:
> "Appropriate access" includes the idea that you need to own the mountpoint
> directory. If you have a system that's so badly run that arbitrary users
> own /tmp, then I'd say user mounts are the least of your problems :-)
True. But the fact is, if I can
On Sat, 24 Jul 1999, Oliver Fromme wrote:
> Ronald G. Minnich wrote in list.freebsd-hackers:
> > Or, let's say I don't have "appropriate access" to /tmp. Pick some other
> > place. I mount my file system there for my files. Now everyone who wants
> > can look for these user mounts and walk th
On Sun, 25 Jul 1999, Brian F. Feldman wrote:
> On Sun, 25 Jul 1999, Mark Newton wrote:
>
> > Ronald G. Minnich wrote:
> > > But thanks for the note. I just now realized that if I add a private name
> > > space to v9fs (which is easy), and then turn on user mounts, user
> > > processes can h
On Sun, 25 Jul 1999, Mark Newton wrote:
> "Appropriate access" includes the idea that you need to own the mountpoint
> directory. If you have a system that's so badly run that arbitrary users
> own /tmp, then I'd say user mounts are the least of your problems :-)
True. But the fact is, if I ca
On Sat, 24 Jul 1999, Oliver Fromme wrote:
> Ronald G. Minnich wrote in list.freebsd-hackers:
> > Or, let's say I don't have "appropriate access" to /tmp. Pick some other
> > place. I mount my file system there for my files. Now everyone who wants
> > can look for these user mounts and walk t
Mark Newton wrote:
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait to see the security problems that causes when setuid
On Sun, 25 Jul 1999, Mark Newton wrote:
> Ronald G. Minnich wrote:
>
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait t
Mark Newton wrote:
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait to see the security problems that causes when setuid
On Sun, 25 Jul 1999, Mark Newton wrote:
> Ronald G. Minnich wrote:
>
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait
Ronald G. Minnich wrote:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > > Are you saying that as an ordinary user I can mount something on top of
> > > /tmp, for example?
> > If the vfs.usermount sysctl is 1, and you have appropriate access t
Ronald G. Minnich wrote:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > > Are you saying that as an ordinary user I can mount something on top of
> > > /tmp, for example?
> > If the vfs.usermount sysctl is 1, and you have appropriate access
Ronald G. Minnich wrote in list.freebsd-hackers:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > > Are you saying that as an ordinary user I can mount something on top of
> > > /tmp, for example?
> > If the vfs.usermount sysctl is 1, and you ha
Ronald G. Minnich wrote in list.freebsd-hackers:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > > Are you saying that as an ordinary user I can mount something on top of
> > > /tmp, for example?
> > If the vfs.usermount sysctl is 1, and you h
On Fri, 23 Jul 1999, Kris Kennaway wrote:
> On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > Are you saying that as an ordinary user I can mount something on top of
> > /tmp, for example?
> If the vfs.usermount sysctl is 1, and you have appropriate access to the
> thing you're trying to mount (
On Fri, 23 Jul 1999, Kris Kennaway wrote:
> On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> > Are you saying that as an ordinary user I can mount something on top of
> > /tmp, for example?
> If the vfs.usermount sysctl is 1, and you have appropriate access to the
> thing you're trying to mount
On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > Well, if you're running it as a kernel module then obviously you need root
> > permissions to load it. If it's running as a userland process, then
> > there's no reason why you can't run it as a user. mou
On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> On Fri, 23 Jul 1999, Kris Kennaway wrote:
> > Well, if you're running it as a kernel module then obviously you need root
> > permissions to load it. If it's running as a userland process, then
> > there's no reason why you can't run it as a user. mo
On Thu, 22 Jul 1999, Tiny Non Cats wrote:
> On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said:
> > Since I am planning on writing userfs in order to impliment 'nsd' (and
> >
> This may be completely useless, because I've not been following what you want
> to do with 'nsd', but you may f
On Fri, 23 Jul 1999, Kris Kennaway wrote:
> Well, if you're running it as a kernel module then obviously you need root
> permissions to load it. If it's running as a userland process, then
> there's no reason why you can't run it as a user. mount presumably
> wouldn't care as long as you had acces
On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> what if you're not root, and you want to add your own file system to your
> file system name space? It seems a lot of these systems assume root
> access, which seems unrealistic to me.
Well, if you're running it as a kernel module then obviously you
what if you're not root, and you want to add your own file system to your
file system name space? It seems a lot of these systems assume root
access, which seems unrealistic to me.
ron
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the mess
On Thu, 22 Jul 1999, Tiny Non Cats wrote:
> On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said:
> > Since I am planning on writing userfs in order to impliment 'nsd' (and
> >
> This may be completely useless, because I've not been following what you want
> to do with 'nsd', but you may
On Fri, 23 Jul 1999, Kris Kennaway wrote:
> Well, if you're running it as a kernel module then obviously you need root
> permissions to load it. If it's running as a userland process, then
> there's no reason why you can't run it as a user. mount presumably
> wouldn't care as long as you had acce
On Thu, 22 Jul 1999, Ronald G. Minnich wrote:
> what if you're not root, and you want to add your own file system to your
> file system name space? It seems a lot of these systems assume root
> access, which seems unrealistic to me.
Well, if you're running it as a kernel module then obviously yo
what if you're not root, and you want to add your own file system to your
file system name space? It seems a lot of these systems assume root
access, which seems unrealistic to me.
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
One last thing: if you're writing userfs you might want to look at
www.inter-mezzo.org
ron
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
One last thing: if you're writing userfs you might want to look at
www.inter-mezzo.org
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said:
> Since I am planning on writing userfs in order to impliment 'nsd' (and
>
This may be completely useless, because I've not been following what you want
to do with 'nsd', but you may find
http://www.cs.columbia.edu/~ezk/research/secu
Since I am planning on writing userfs in order to impliment 'nsd' (and
some other ideas I have hatching too :). I need to know how filesystem
accesses work. Can they be queued up, and responded to out of order?
For example... I have a request come in (via the filesystem), that request
is going t
On Thu, Jul 22, 1999 at 10:06:04AM -0400 David E. Cross said:
> Since I am planning on writing userfs in order to impliment 'nsd' (and
>
This may be completely useless, because I've not been following what you want
to do with 'nsd', but you may find
http://www.cs.columbia.edu/~ezk/research/sec
Since I am planning on writing userfs in order to impliment 'nsd' (and
some other ideas I have hatching too :). I need to know how filesystem
accesses work. Can they be queued up, and responded to out of order?
For example... I have a request come in (via the filesystem), that request
is going
42 matches
Mail list logo
