Re: FUSE merging?
> > Yes, it may confuse the user. It may even confuse the kernel for > > sticky directories(*). But basically it just works, and is very > > simple. > > > > In principal, Plan 9 file servers handle permission checking > server-side, so we could likewise punt -- but it seemed a good idea to > have some form of mapping for directory listings (and things like > sticky directories) to make sense. Yes if the user/group names are available (as in 9P), then doing the mapping based on /etc/passwd for example makes sense. But sshfs only transfers the numeric uid/gid, and hence there's simply no info to base any transformation on. It could transfer /etc/passwd from the remote server, and use that to do mapping, but that is getting more complex than the problem actually warrants IMO. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 9/3/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > While FUSE doesn't handle it directly, doesn't it have to punt it to > > its network file systems, how to the sshfs and what not handle this > > sort of mapping? > > Sshfs handles it by not handling it. In this case it is neither > possible, nor needed to be able to correctly map the id space. > > Yes, it may confuse the user. It may even confuse the kernel for > sticky directories(*). But basically it just works, and is very > simple. > In principal, Plan 9 file servers handle permission checking server-side, so we could likewise punt -- but it seemed a good idea to have some form of mapping for directory listings (and things like sticky directories) to make sense. -eric - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
> While FUSE doesn't handle it directly, doesn't it have to punt it to > its network file systems, how to the sshfs and what not handle this > sort of mapping? Sshfs handles it by not handling it. In this case it is neither possible, nor needed to be able to correctly map the id space. Yes, it may confuse the user. It may even confuse the kernel for sticky directories(*). But basically it just works, and is very simple. > Not really a criticism, just curious. This doesn't so much relate > to FUSE, but I've been wrestling with what to do about this chunk of > (mapping) code -- it seems like it might be a good idea to have some > common code shared amongst the networked file systems to handle this > sort of thing. The NFS idmapd service seems overcomplicated, but > something like that in the common code could provide the same level > of service. What do folks think? Should someone (me?) take a whack > at a common id mapping service for the kernel (or just extract > idmapd from NFS) -- or is this something better implemented > filesystem-to-filesystem? If more than one filesystem would use it, it would make sense to abstract it out. FUSE doesn't need it since it can happily do the mapping in userspace. Miklos (*) I think the correct behavior would be if checking sticky permissions could also be delegated to the filesystem, like checking normal permissions can be. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 9/3/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > I agree that lots of people would like the functionality. I regret that > > although it appears that v9fs could provide it, > > I think you are wrong there. You don't appreciate all the complexity > FUSE _lacks_ by not being network transparent. Just look at the error > text to errno conversion muck that v9fs has. And their problems with > trying to do generic uid/gid mappings. > While FUSE doesn't handle it directly, doesn't it have to punt it to its network file systems, how to the sshfs and what not handle this sort of mapping? Not really a criticism, just curious. This doesn't so much relate to FUSE, but I've been wrestling with what to do about this chunk of (mapping) code -- it seems like it might be a good idea to have some common code shared amongst the networked file systems to handle this sort of thing. The NFS idmapd service seems overcomplicated, but something like that in the common code could provide the same level of service. What do folks think? Should someone (me?) take a whack at a common id mapping service for the kernel (or just extract idmapd from NFS) -- or is this something better implemented filesystem-to-filesystem? > > there seems to be no interest in working on that. > > It would mean adding a plethora of extensions to the 9P protocol, that > would take away all it's beauty. I think you should realize that > these are different interfaces for different purposes. There may be > some overlap, but not enough to warrant trying to massage them into > one big ball. > A very good point. I toyed with the idea of looking at creating a FUSE-API-compatible v9fs file server library - but there are a good deal of features (like extended attributes) that we don't have provisions for in the protocol -- and most likely a good deal of complexity supporting some of these features that we may not want to deal with just yet. Miklos is right, for the moment FUSE and v9fs have some overlap, but they remain very different things. FUSE is far more focused on delivering user-space file servers, and as such has a better solution for developing user-space file servers. We are still focusing on getting the core of v9fs worked out, when we eventually have that working smoothly, I like to think we'd be able to spend some time developing a file server SDK as rich as FUSE (perhaps something API-compatible as I mentioned before) -- but we want to focus on getting the core protocol implementation right first - since it has uses beyond user-space file servers. -eric - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [fuse-devel] Re: FUSE merging?
- number of language bindings: 7 (native: C, java, python, perl, - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. 9 now (there is an ocaml binding, and if you dont know ocaml, shame on you). I would just like to add "please, merge fuse in linux, pleas" I am an happy user of debian so I have no problem, but when I want other people to install my fuse-advanced-not-yet-public-like-spotlight-and- winfs-just-beter filesystem, then there is a big problem. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
> > > The main sticking point with FUSE remains the permission tricks around > > > fuse_allow_task(). AFAIK it remains the case that nobody has come up > > with > > > any better idea, so I'm inclined to merge the thing. > > > > Do you promise? > > I troll. What others think matters. But at this stage, objections would > need to be substantial, IMO. Fair enough. > We're rather deadlocked on the permission thing, but if we can't > come up with anything better then I'm inclined to say what-the-hell. There's no disadvantage IMO. It adds nearly zero complexity. If someone doesn't like it, it can be configured out in userspace. And it leaves no legacy interfaces to support if later a better method is found. > > I can do a resplit and submit to Linus, if that takes > > some load off you. > > Nah, then I'd just have to check that everything is the same. OK. Thanks, Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > The main sticking point with FUSE remains the permission tricks around > > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > > any better idea, so I'm inclined to merge the thing. > > Do you promise? I troll. What others think matters. But at this stage, objections would need to be substantial, IMO. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell. > I can do a resplit and submit to Linus, if that takes > some load off you. Nah, then I'd just have to check that everything is the same. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Miklos Szeredi [EMAIL PROTECTED] wrote: The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. Do you promise? I troll. What others think matters. But at this stage, objections would need to be substantial, IMO. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell. I can do a resplit and submit to Linus, if that takes some load off you. Nah, then I'd just have to check that everything is the same. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. Do you promise? I troll. What others think matters. But at this stage, objections would need to be substantial, IMO. Fair enough. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell. There's no disadvantage IMO. It adds nearly zero complexity. If someone doesn't like it, it can be configured out in userspace. And it leaves no legacy interfaces to support if later a better method is found. I can do a resplit and submit to Linus, if that takes some load off you. Nah, then I'd just have to check that everything is the same. OK. Thanks, Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [fuse-devel] Re: FUSE merging?
- number of language bindings: 7 (native: C, java, python, perl, - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. 9 now (there is an ocaml binding, and if you dont know ocaml, shame on you). I would just like to add please, merge fuse in linux, pleas I am an happy user of debian so I have no problem, but when I want other people to install my fuse-advanced-not-yet-public-like-spotlight-and- winfs-just-beter filesystem, then there is a big problem. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 9/3/05, Miklos Szeredi [EMAIL PROTECTED] wrote: I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, I think you are wrong there. You don't appreciate all the complexity FUSE _lacks_ by not being network transparent. Just look at the error text to errno conversion muck that v9fs has. And their problems with trying to do generic uid/gid mappings. While FUSE doesn't handle it directly, doesn't it have to punt it to its network file systems, how to the sshfs and what not handle this sort of mapping? Not really a criticism, just curious. This doesn't so much relate to FUSE, but I've been wrestling with what to do about this chunk of (mapping) code -- it seems like it might be a good idea to have some common code shared amongst the networked file systems to handle this sort of thing. The NFS idmapd service seems overcomplicated, but something like that in the common code could provide the same level of service. What do folks think? Should someone (me?) take a whack at a common id mapping service for the kernel (or just extract idmapd from NFS) -- or is this something better implemented filesystem-to-filesystem? there seems to be no interest in working on that. It would mean adding a plethora of extensions to the 9P protocol, that would take away all it's beauty. I think you should realize that these are different interfaces for different purposes. There may be some overlap, but not enough to warrant trying to massage them into one big ball. A very good point. I toyed with the idea of looking at creating a FUSE-API-compatible v9fs file server library - but there are a good deal of features (like extended attributes) that we don't have provisions for in the protocol -- and most likely a good deal of complexity supporting some of these features that we may not want to deal with just yet. Miklos is right, for the moment FUSE and v9fs have some overlap, but they remain very different things. FUSE is far more focused on delivering user-space file servers, and as such has a better solution for developing user-space file servers. We are still focusing on getting the core of v9fs worked out, when we eventually have that working smoothly, I like to think we'd be able to spend some time developing a file server SDK as rich as FUSE (perhaps something API-compatible as I mentioned before) -- but we want to focus on getting the core protocol implementation right first - since it has uses beyond user-space file servers. -eric - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
While FUSE doesn't handle it directly, doesn't it have to punt it to its network file systems, how to the sshfs and what not handle this sort of mapping? Sshfs handles it by not handling it. In this case it is neither possible, nor needed to be able to correctly map the id space. Yes, it may confuse the user. It may even confuse the kernel for sticky directories(*). But basically it just works, and is very simple. Not really a criticism, just curious. This doesn't so much relate to FUSE, but I've been wrestling with what to do about this chunk of (mapping) code -- it seems like it might be a good idea to have some common code shared amongst the networked file systems to handle this sort of thing. The NFS idmapd service seems overcomplicated, but something like that in the common code could provide the same level of service. What do folks think? Should someone (me?) take a whack at a common id mapping service for the kernel (or just extract idmapd from NFS) -- or is this something better implemented filesystem-to-filesystem? If more than one filesystem would use it, it would make sense to abstract it out. FUSE doesn't need it since it can happily do the mapping in userspace. Miklos (*) I think the correct behavior would be if checking sticky permissions could also be delegated to the filesystem, like checking normal permissions can be. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 9/3/05, Miklos Szeredi [EMAIL PROTECTED] wrote: While FUSE doesn't handle it directly, doesn't it have to punt it to its network file systems, how to the sshfs and what not handle this sort of mapping? Sshfs handles it by not handling it. In this case it is neither possible, nor needed to be able to correctly map the id space. Yes, it may confuse the user. It may even confuse the kernel for sticky directories(*). But basically it just works, and is very simple. In principal, Plan 9 file servers handle permission checking server-side, so we could likewise punt -- but it seemed a good idea to have some form of mapping for directory listings (and things like sticky directories) to make sense. -eric - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Yes, it may confuse the user. It may even confuse the kernel for sticky directories(*). But basically it just works, and is very simple. In principal, Plan 9 file servers handle permission checking server-side, so we could likewise punt -- but it seemed a good idea to have some form of mapping for directory listings (and things like sticky directories) to make sense. Yes if the user/group names are available (as in 9P), then doing the mapping based on /etc/passwd for example makes sense. But sshfs only transfers the numeric uid/gid, and hence there's simply no info to base any transformation on. It could transfer /etc/passwd from the remote server, and use that to do mapping, but that is getting more complex than the problem actually warrants IMO. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
> Haven't thought about it all much. Have spent most of my time in the last > month admiring the contents of kernel bugzilla, and the ongoing attempts to > increase them. A penal system could be created, for example if someone is caught introducing a bug, he will have to choose three additional reports from bugzilla and analyze/fix them ;) > > - number of language bindings: 7 (native: C, java, python, perl, > > - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. > I agree that lots of people would like the functionality. I regret that > although it appears that v9fs could provide it, I think you are wrong there. You don't appreciate all the complexity FUSE _lacks_ by not being network transparent. Just look at the error text to errno conversion muck that v9fs has. And their problems with trying to do generic uid/gid mappings. > there seems to be no interest in working on that. It would mean adding a plethora of extensions to the 9P protocol, that would take away all it's beauty. I think you should realize that these are different interfaces for different purposes. There may be some overlap, but not enough to warrant trying to massage them into one big ball. > The main sticking point with FUSE remains the permission tricks around > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > any better idea, so I'm inclined to merge the thing. Do you promise? I can do a resplit and submit to Linus, if that takes some load off you. Thanks, Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > Hi Andrew! > > > > Do you plan to send FUSE to Linus for 2.6.14? > i use fuse too, and i like it, it works good, and its quite fast and easy. it has given me no problems at all, i suggest merging, it harms nothing, and seems to be well maintained > 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 > Please read the FAQ at http://www.tux.org/lkml/ > - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (why I chose FUSE over v9fs)
On Friday 02 September 2005 15:34, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Hi Andrew! > > > > Do you plan to send FUSE to Linus for 2.6.14? ... > I agree that lots of people would like the functionality. I regret that > although it appears that v9fs could provide it, there seems to be no > interest in working on that. I evaluated both v9fs and FUSE for my project (I don't want to link to it until it does something actually useful ;) ) ... and it seemed that v9fs just wasn't UNIXy enough for my purposes -- the Plan9 way and the UNIX way were different enough to make me nervous. I don't remember the specific details (this was a few months ago), but I do remember that v9fs had no extended attribute support, which was a showstopper for me. Also, I couldn't find any userspace library for writing 9P servers. Others may have reached similar conclusions. Or maybe FUSE is just better-marketed. ;) Either way, I am a happy FUSE user. I think it offers things v9fs doesn't, and I'd like to see it in mainline. :) -- Josh -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune pgpeHwGWEoTRr.pgp Description: PGP signature
Re: FUSE merging?
Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Hi Andrew! > > Do you plan to send FUSE to Linus for 2.6.14? Haven't thought about it all much. Have spent most of my time in the last month admiring the contents of kernel bugzilla, and the ongoing attempts to increase them. > I know you have some doubts about usefulness, etc. Here are a couple > of facts, that I hope show that Linux should benefit from having FUSE: > > - total number of downloads from SF: ~25000 > > - number of downloads of last release (during 3 months): ~7000 > > - number of distros carrying official packages: 2 (debian, gentoo) > > - number of publicly available filesystems known: 27 > > - of which at least 2 are carried by debian (and maybe others) > > - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) > > - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s > > - mailing list traffic 100-200 messages/month > > - have been in -mm since 2005 january > I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that. The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. - 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 Please read the FAQ at http://www.tux.org/lkml/
FUSE merging?
Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? I know you have some doubts about usefulness, etc. Here are a couple of facts, that I hope show that Linux should benefit from having FUSE: - total number of downloads from SF: ~25000 - number of downloads of last release (during 3 months): ~7000 - number of distros carrying official packages: 2 (debian, gentoo) - number of publicly available filesystems known: 27 - of which at least 2 are carried by debian (and maybe others) - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s - mailing list traffic 100-200 messages/month - have been in -mm since 2005 january Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
FUSE merging?
Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? I know you have some doubts about usefulness, etc. Here are a couple of facts, that I hope show that Linux should benefit from having FUSE: - total number of downloads from SF: ~25000 - number of downloads of last release (during 3 months): ~7000 - number of distros carrying official packages: 2 (debian, gentoo) - number of publicly available filesystems known: 27 - of which at least 2 are carried by debian (and maybe others) - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s - mailing list traffic 100-200 messages/month - have been in -mm since 2005 january Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Miklos Szeredi [EMAIL PROTECTED] wrote: Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? Haven't thought about it all much. Have spent most of my time in the last month admiring the contents of kernel bugzilla, and the ongoing attempts to increase them. I know you have some doubts about usefulness, etc. Here are a couple of facts, that I hope show that Linux should benefit from having FUSE: - total number of downloads from SF: ~25000 - number of downloads of last release (during 3 months): ~7000 - number of distros carrying official packages: 2 (debian, gentoo) - number of publicly available filesystems known: 27 - of which at least 2 are carried by debian (and maybe others) - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s - mailing list traffic 100-200 messages/month - have been in -mm since 2005 january I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that. The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (why I chose FUSE over v9fs)
On Friday 02 September 2005 15:34, Andrew Morton wrote: Miklos Szeredi [EMAIL PROTECTED] wrote: Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? ... I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that. I evaluated both v9fs and FUSE for my project (I don't want to link to it until it does something actually useful ;) ) ... and it seemed that v9fs just wasn't UNIXy enough for my purposes -- the Plan9 way and the UNIX way were different enough to make me nervous. I don't remember the specific details (this was a few months ago), but I do remember that v9fs had no extended attribute support, which was a showstopper for me. Also, I couldn't find any userspace library for writing 9P servers. Others may have reached similar conclusions. Or maybe FUSE is just better-marketed. ;) Either way, I am a happy FUSE user. I think it offers things v9fs doesn't, and I'd like to see it in mainline. :) -- Josh -- Joshua J. Berry I haven't lost my mind -- it's backed up on tape somewhere. -- /usr/games/fortune pgpeHwGWEoTRr.pgp Description: PGP signature
Re: FUSE merging?
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote: Miklos Szeredi [EMAIL PROTECTED] wrote: Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? snip i use fuse too, and i like it, it works good, and its quite fast and easy. it has given me no problems at all, i suggest merging, it harms nothing, and seems to be well maintained 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 Please read the FAQ at http://www.tux.org/lkml/ - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Haven't thought about it all much. Have spent most of my time in the last month admiring the contents of kernel bugzilla, and the ongoing attempts to increase them. A penal system could be created, for example if someone is caught introducing a bug, he will have to choose three additional reports from bugzilla and analyze/fix them ;) - number of language bindings: 7 (native: C, java, python, perl, - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, I think you are wrong there. You don't appreciate all the complexity FUSE _lacks_ by not being network transparent. Just look at the error text to errno conversion muck that v9fs has. And their problems with trying to do generic uid/gid mappings. there seems to be no interest in working on that. It would mean adding a plethora of extensions to the 9P protocol, that would take away all it's beauty. I think you should realize that these are different interfaces for different purposes. There may be some overlap, but not enough to warrant trying to massage them into one big ball. The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing. Do you promise? I can do a resplit and submit to Linus, if that takes some load off you. Thanks, Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 03:17:35PM +0200, Miklos Szeredi wrote: > > > I see your point. But then this is really not a security issue, but > > > an "are you sure you want to format C:" style protection for the > > > user's own sake. Adding a mount option (checked by the library) for > > > this would be fine. E.g. with "mount_nonempty" it would not refuse to > > > mount on a non-leaf dir, and README would document, that using this > > > option might cause trouble. Otherwise the mount would be refused with > > > a reference to the above option. > > > > IMO that should be a generic mount option, not FUSE specific. > > Maybe the default could vary for each fs, but I'd vote against that. Why a mount option at all? Why not just a switch for the mount utility? > The option only makes sense with the default being restrictive. But > making that default for all filesystems can't be done, because that > would immediately break thousands of existing installations. I think it is acceptable to change this behaviour in a new version of the mount utility. One could considder ignoring the restriction when running with "-a" or when running as root - that would reduce or eliminate the problems with the transition. However, if this is implemented in mount itself, it is totally orthogonal to the FUSE merge discussion. -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
> > I see your point. But then this is really not a security issue, but > > an "are you sure you want to format C:" style protection for the > > user's own sake. Adding a mount option (checked by the library) for > > this would be fine. E.g. with "mount_nonempty" it would not refuse to > > mount on a non-leaf dir, and README would document, that using this > > option might cause trouble. Otherwise the mount would be refused with > > a reference to the above option. > > IMO that should be a generic mount option, not FUSE specific. > Maybe the default could vary for each fs, but I'd vote against that. The option only makes sense with the default being restrictive. But making that default for all filesystems can't be done, because that would immediately break thousands of existing installations. I think this makes some sense for unprivileged mounts, but otherwise not really. If sysadmin is not careful about where the mounts go, tough luck on him. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
Miklos Szeredi <[EMAIL PROTECTED]> wrote: > I see your point. But then this is really not a security issue, but > an "are you sure you want to format C:" style protection for the > user's own sake. Adding a mount option (checked by the library) for > this would be fine. E.g. with "mount_nonempty" it would not refuse to > mount on a non-leaf dir, and README would document, that using this > option might cause trouble. Otherwise the mount would be refused with > a reference to the above option. IMO that should be a generic mount option, not FUSE specific. Maybe the default could vary for each fs, but I'd vote against that. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 12:27:13PM +0200, Miklos Szeredi wrote: > E.g. with "mount_nonempty" it would not refuse to > mount on a non-leaf dir, and README would document, that using this > option might cause trouble. Otherwise the mount would be refused with > a reference to the above option. that will do. -- Frank - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 7/4/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Here are some numbers on the size these filesystems as in current -mm
> ('wc fs/${fs}/* include/linux/${fs}*')
Sloccount [1] gives more meaningful numbers than wc:
('sloccount fs/${fs}/* include/linux/${fs}*')
nfs: 21,046
9p:3,856
coda: 3,358
fuse: 2,829
1. http://www.dwheeler.com/sloccount/
Pekka
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
> "solving it properly" refers to hardening the leaf node constraint > against circumvention I assume. Suppose there's a script for doing simple > on-line backups using "find". Now explain to the user why he lost his > data due to a backup script geting EACCES on a non-leaf FUSE mount. I see your point. But then this is really not a security issue, but an "are you sure you want to format C:" style protection for the user's own sake. Adding a mount option (checked by the library) for this would be fine. E.g. with "mount_nonempty" it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. Is that what you were thinking? > > There's a nice solution to this (discussed at length earlier): private > > namespaces. > > I thought that's rejected because a process doesn't automatically get the > right namespace after rsh into such a machine? And fixing it by adjusting > the name-space of a process (by whatever means) is not transparent. Private namespaces in their current form are not really useful. But that's irrelevant to the current discussion. If somebody needs private namespaces they will have to add the missing features (Ram Pai is working on shared subtrees, the biggest chunk). > > I think we are still confusing these two issues, which are in fact > > separate. > > > > 1) polluting global namespace is bad (find -xdev issue) > > > > 2) not ptraceable (or not killable) processes should not be able to > > access an unprivileged mount > > > > For 1) private namespaces are the proper solution. For 2) the > > fuse_allow_task() in it's current or modified form (to check > > killability) should be OK. > > > > 1) is completely orthogonal to FUSE. 2) is currently provably secure, > > and doesn't seem cause problems in practice. Do you have a concrete > > example, where it would cause problems? > > See above backup scenario. The backup problem is a consequence of 1). It has absolutely zero to do with 2). If the fuse_allow_task() security check didn't exist the backup script would still not work. > Issues (1) and (2) are tied together I'm afraid: > > When using a private name-space and thus assuming an unrelated process > needs to do something very special to get that name-space then (2) > would not be needed at all. Wrong. It's still needed, because suid/sgid programs can - run under the private namespace without doing anything special - run with extra privileges, not possesed by the user executing the program > On the other hand, Name-space inheritance by setuid processes suddenly > becomes an issue: issue (2) is re-appearing but at another place. I don't think you could change the rules of namespace inheritence, without causing trouble. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote: > > It is important because on UNIX, "root" rules on local filesystems. > > I dont't like the idea of root not being able to run "find -xdev" > > anymore for administrative tasks, just because something got hidden > > by accident or just for fun by a user. It's not about malicious > > users who want to hide data: they can do that in tons of ways. > > That's a sort of security by obscurity: if the user is dumb enough he > cannot do any harm. But I'm not interested in that sort of thing. If > this issue important, then it should be solved properly, and not just > by "preventing accidents". "solving it properly" refers to hardening the leaf node constraint against circumvention I assume. Suppose there's a script for doing simple on-line backups using "find". Now explain to the user why he lost his data due to a backup script geting EACCES on a non-leaf FUSE mount. I don't think that's acceptable. On the other hand, when the user stored something _deliberately_ under a mountpoint, circumventing the leaf node constraint by some trickery then it is clearly his own fault when the data is lost. Anyway, a leaf node constraint can be hardened against misuse later on, should it become necessary. Your bind-mount case to circumvent this restriction is slightly flawed because it requires root interaction. > > There's a nice solution to this (discussed at length earlier): private > namespaces. I thought that's rejected because a process doesn't automatically get the right namespace after rsh into such a machine? And fixing it by adjusting the name-space of a process (by whatever means) is not transparent. > I think we are still confusing these two issues, which are in fact > separate. > > 1) polluting global namespace is bad (find -xdev issue) > > 2) not ptraceable (or not killable) processes should not be able to > access an unprivileged mount > > For 1) private namespaces are the proper solution. For 2) the > fuse_allow_task() in it's current or modified form (to check > killability) should be OK. > > 1) is completely orthogonal to FUSE. 2) is currently provably secure, > and doesn't seem cause problems in practice. Do you have a concrete > example, where it would cause problems? See above backup scenario. Issues (1) and (2) are tied together I'm afraid: When using a private name-space and thus assuming an unrelated process needs to do something very special to get that name-space then (2) would not be needed at all. On the other hand, Name-space inheritance by setuid processes suddenly becomes an issue: issue (2) is re-appearing but at another place. -- Frank - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
[CC restored]
> Okay, I just wanted to mention CODA. Modifying CODA is probably still
> better than modifying NFS (as akpm suggested at one point).
Definitely.
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
nfs: 25495
9p:6102
coda: 4752
fuse: 3733
I'm sure FUSE came out smallest because I'm biased and did something
wrong ;)
Miklos
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
> It is important because on UNIX, "root" rules on local filesystems. > I dont't like the idea of root not being able to run "find -xdev" > anymore for administrative tasks, just because something got hidden > by accident or just for fun by a user. It's not about malicious > users who want to hide data: they can do that in tons of ways. That's a sort of security by obscurity: if the user is dumb enough he cannot do any harm. But I'm not interested in that sort of thing. If this issue important, then it should be solved properly, and not just by "preventing accidents". > IMHO The best thing FUSE could do is to make the mount totally > invisible: don't return EACCES, don't follow the FUSE mount but stay > on the original tree. I think it's either this or returning EACCES > plus the leaf node constraint at mount time. The leaf node constranint doesn't make sense. The hidden mount thing does, but it has been very flatly rejected by Al Viro. There's a nice solution to this (discussed at length earlier): private namespaces. I think we are still confusing these two issues, which are in fact separate. 1) polluting global namespace is bad (find -xdev issue) 2) not ptraceable (or not killable) processes should not be able to access an unprivileged mount For 1) private namespaces are the proper solution. For 2) the fuse_allow_task() in it's current or modified form (to check killability) should be OK. 1) is completely orthogonal to FUSE. 2) is currently provably secure, and doesn't seem cause problems in practice. Do you have a concrete example, where it would cause problems? Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
> Actually, the right question is "how is fuse better than coda". I've > asked that before; unlike nfs, userspace filesystems implemented with > coda actually *work*, but do not provide partial-file writes. You answered your own question. I did talk to Jan Harkes about the file I/O issue before starting FUSE. [searching archives] here's a quote from him about this: "I've been thinking about partial file accesses myself. However, I really don't want to go all the way to block-level caching. That would add a lot of overhead either in passing every read/write call up to userspace, or by using a largish amount of memory to keep track of availability of parts of the file. It also defeats the more efficient 'streaming' fetch of a whole file. However, something that would work reasonably well is a file offset marker that indicates how much data is available. Basically, when the application opens a file, the open upcall returns after the first... let's say 64KB... have arrived. Any read's and write (and mmap's) that access the available part of the file will be allowed. When any operation tries to access beyond the marker an upcall is made which blocks until the related part of the file has streamed in." So true random access doesn't fit too well into the CODA philosophy. Of course you could extend CODA to handle this as well (and all the other things needed for safe user mounts), but the results would proably not have pleased either side. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
Actually, the right question is how is fuse better than coda. I've asked that before; unlike nfs, userspace filesystems implemented with coda actually *work*, but do not provide partial-file writes. You answered your own question. I did talk to Jan Harkes about the file I/O issue before starting FUSE. [searching archives] here's a quote from him about this: I've been thinking about partial file accesses myself. However, I really don't want to go all the way to block-level caching. That would add a lot of overhead either in passing every read/write call up to userspace, or by using a largish amount of memory to keep track of availability of parts of the file. It also defeats the more efficient 'streaming' fetch of a whole file. However, something that would work reasonably well is a file offset marker that indicates how much data is available. Basically, when the application opens a file, the open upcall returns after the first... let's say 64KB... have arrived. Any read's and write (and mmap's) that access the available part of the file will be allowed. When any operation tries to access beyond the marker an upcall is made which blocks until the related part of the file has streamed in. So true random access doesn't fit too well into the CODA philosophy. Of course you could extend CODA to handle this as well (and all the other things needed for safe user mounts), but the results would proably not have pleased either side. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
It is important because on UNIX, root rules on local filesystems. I dont't like the idea of root not being able to run find -xdev anymore for administrative tasks, just because something got hidden by accident or just for fun by a user. It's not about malicious users who want to hide data: they can do that in tons of ways. That's a sort of security by obscurity: if the user is dumb enough he cannot do any harm. But I'm not interested in that sort of thing. If this issue important, then it should be solved properly, and not just by preventing accidents. IMHO The best thing FUSE could do is to make the mount totally invisible: don't return EACCES, don't follow the FUSE mount but stay on the original tree. I think it's either this or returning EACCES plus the leaf node constraint at mount time. The leaf node constranint doesn't make sense. The hidden mount thing does, but it has been very flatly rejected by Al Viro. There's a nice solution to this (discussed at length earlier): private namespaces. I think we are still confusing these two issues, which are in fact separate. 1) polluting global namespace is bad (find -xdev issue) 2) not ptraceable (or not killable) processes should not be able to access an unprivileged mount For 1) private namespaces are the proper solution. For 2) the fuse_allow_task() in it's current or modified form (to check killability) should be OK. 1) is completely orthogonal to FUSE. 2) is currently provably secure, and doesn't seem cause problems in practice. Do you have a concrete example, where it would cause problems? Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
[CC restored]
Okay, I just wanted to mention CODA. Modifying CODA is probably still
better than modifying NFS (as akpm suggested at one point).
Definitely.
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
nfs: 25495
9p:6102
coda: 4752
fuse: 3733
I'm sure FUSE came out smallest because I'm biased and did something
wrong ;)
Miklos
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote: It is important because on UNIX, root rules on local filesystems. I dont't like the idea of root not being able to run find -xdev anymore for administrative tasks, just because something got hidden by accident or just for fun by a user. It's not about malicious users who want to hide data: they can do that in tons of ways. That's a sort of security by obscurity: if the user is dumb enough he cannot do any harm. But I'm not interested in that sort of thing. If this issue important, then it should be solved properly, and not just by preventing accidents. solving it properly refers to hardening the leaf node constraint against circumvention I assume. Suppose there's a script for doing simple on-line backups using find. Now explain to the user why he lost his data due to a backup script geting EACCES on a non-leaf FUSE mount. I don't think that's acceptable. On the other hand, when the user stored something _deliberately_ under a mountpoint, circumventing the leaf node constraint by some trickery then it is clearly his own fault when the data is lost. Anyway, a leaf node constraint can be hardened against misuse later on, should it become necessary. Your bind-mount case to circumvent this restriction is slightly flawed because it requires root interaction. There's a nice solution to this (discussed at length earlier): private namespaces. I thought that's rejected because a process doesn't automatically get the right namespace after rsh into such a machine? And fixing it by adjusting the name-space of a process (by whatever means) is not transparent. I think we are still confusing these two issues, which are in fact separate. 1) polluting global namespace is bad (find -xdev issue) 2) not ptraceable (or not killable) processes should not be able to access an unprivileged mount For 1) private namespaces are the proper solution. For 2) the fuse_allow_task() in it's current or modified form (to check killability) should be OK. 1) is completely orthogonal to FUSE. 2) is currently provably secure, and doesn't seem cause problems in practice. Do you have a concrete example, where it would cause problems? See above backup scenario. Issues (1) and (2) are tied together I'm afraid: When using a private name-space and thus assuming an unrelated process needs to do something very special to get that name-space then (2) would not be needed at all. On the other hand, Name-space inheritance by setuid processes suddenly becomes an issue: issue (2) is re-appearing but at another place. -- Frank - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
solving it properly refers to hardening the leaf node constraint against circumvention I assume. Suppose there's a script for doing simple on-line backups using find. Now explain to the user why he lost his data due to a backup script geting EACCES on a non-leaf FUSE mount. I see your point. But then this is really not a security issue, but an are you sure you want to format C: style protection for the user's own sake. Adding a mount option (checked by the library) for this would be fine. E.g. with mount_nonempty it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. Is that what you were thinking? There's a nice solution to this (discussed at length earlier): private namespaces. I thought that's rejected because a process doesn't automatically get the right namespace after rsh into such a machine? And fixing it by adjusting the name-space of a process (by whatever means) is not transparent. Private namespaces in their current form are not really useful. But that's irrelevant to the current discussion. If somebody needs private namespaces they will have to add the missing features (Ram Pai is working on shared subtrees, the biggest chunk). I think we are still confusing these two issues, which are in fact separate. 1) polluting global namespace is bad (find -xdev issue) 2) not ptraceable (or not killable) processes should not be able to access an unprivileged mount For 1) private namespaces are the proper solution. For 2) the fuse_allow_task() in it's current or modified form (to check killability) should be OK. 1) is completely orthogonal to FUSE. 2) is currently provably secure, and doesn't seem cause problems in practice. Do you have a concrete example, where it would cause problems? See above backup scenario. The backup problem is a consequence of 1). It has absolutely zero to do with 2). If the fuse_allow_task() security check didn't exist the backup script would still not work. Issues (1) and (2) are tied together I'm afraid: When using a private name-space and thus assuming an unrelated process needs to do something very special to get that name-space then (2) would not be needed at all. Wrong. It's still needed, because suid/sgid programs can - run under the private namespace without doing anything special - run with extra privileges, not possesed by the user executing the program On the other hand, Name-space inheritance by setuid processes suddenly becomes an issue: issue (2) is re-appearing but at another place. I don't think you could change the rules of namespace inheritence, without causing trouble. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On 7/4/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
Sloccount [1] gives more meaningful numbers than wc:
('sloccount fs/${fs}/* include/linux/${fs}*')
nfs: 21,046
9p:3,856
coda: 3,358
fuse: 2,829
1. http://www.dwheeler.com/sloccount/
Pekka
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 12:27:13PM +0200, Miklos Szeredi wrote: E.g. with mount_nonempty it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. that will do. -- Frank - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
Miklos Szeredi [EMAIL PROTECTED] wrote: I see your point. But then this is really not a security issue, but an are you sure you want to format C: style protection for the user's own sake. Adding a mount option (checked by the library) for this would be fine. E.g. with mount_nonempty it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. IMO that should be a generic mount option, not FUSE specific. Maybe the default could vary for each fs, but I'd vote against that. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
I see your point. But then this is really not a security issue, but an are you sure you want to format C: style protection for the user's own sake. Adding a mount option (checked by the library) for this would be fine. E.g. with mount_nonempty it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. IMO that should be a generic mount option, not FUSE specific. Maybe the default could vary for each fs, but I'd vote against that. The option only makes sense with the default being restrictive. But making that default for all filesystems can't be done, because that would immediately break thousands of existing installations. I think this makes some sense for unprivileged mounts, but otherwise not really. If sysadmin is not careful about where the mounts go, tough luck on him. Miklos - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging? (2)
On Mon, Jul 04, 2005 at 03:17:35PM +0200, Miklos Szeredi wrote: I see your point. But then this is really not a security issue, but an are you sure you want to format C: style protection for the user's own sake. Adding a mount option (checked by the library) for this would be fine. E.g. with mount_nonempty it would not refuse to mount on a non-leaf dir, and README would document, that using this option might cause trouble. Otherwise the mount would be refused with a reference to the above option. IMO that should be a generic mount option, not FUSE specific. Maybe the default could vary for each fs, but I'd vote against that. Why a mount option at all? Why not just a switch for the mount utility? The option only makes sense with the default being restrictive. But making that default for all filesystems can't be done, because that would immediately break thousands of existing installations. I think it is acceptable to change this behaviour in a new version of the mount utility. One could considder ignoring the restriction when running with -a or when running as root - that would reduce or eliminate the problems with the transition. However, if this is implemented in mount itself, it is totally orthogonal to the FUSE merge discussion. -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter - 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 Please read the FAQ at http://www.tux.org/lkml/
