From: Nic J. F. <nfe...@ta...> - 2007-03-12 13:55:58
|
I'm trying to run a simple python fuse wrapper with allow_other and allow_root and it's not working. I can't find a single decent piece of documentation on how to do this, with an actual example of a command line. I've got the following debian packages: fuse-module-2.6.16-2-686 2.5.3-2+2.6.16-14 fuse-source 2.5.3-2 fuse-utils 2.6.3-1 libfuse2 2.5.3-4.1 python-fuse 2.5-5+b1 I have setup /etc/fuse.conf like so: user_allow_other Either using the xmp.py example or the example on the wiki page I've tried starting it like this: python /usr/share/doc/python-fuse/examples/xmp.py ../mnt --allow_root and this: python /usr/share/doc/python-fuse/examples/xmp.py ../mnt allow_root and this: python /usr/share/doc/python-fuse/examples/xmp.py ../mnt -o allow_root and this: python /usr/share/doc/python-fuse/examples/xmp.py ../mnt allow_root=yes But I always get a permissions failure. Can anyone help? -- Nic Ferrier ---------------------------------------------------------- Need a linux/java/python/web hacker? I'm in need of work! ---------------------------------------------------------- http://www.tapsellferrier.co.uk |
From: Csaba H. <csa...@cr...> - 2007-03-13 12:35:54
|
On 2007-03-12, Nic James Ferrier <nfe...@ta...> wrote: > I'm trying to run a simple python fuse wrapper with allow_other and > allow_root and it's not working. > I can't find a single decent piece of documentation on how to do this, > with an actual example of a command line. > > I've got the following debian packages: > > fuse-module-2.6.16-2-686 2.5.3-2+2.6.16-14 > fuse-source 2.5.3-2 > fuse-utils 2.6.3-1 > libfuse2 2.5.3-4.1 > python-fuse 2.5-5+b1 Only the devel version of the python bindings provides fuselib-compatible option parsing... With the older version the filesystems are left alone in this respect. They can implement fuselib like parsing themselves, however, that's not done by xmp.py. IIRC Debian still ships the oldie but properly released (and are waiting for me to roll out a new release for the new stuff). > I have setup /etc/fuse.conf like so: > > user_allow_other > [...] > and this: > > python /usr/share/doc/python-fuse/examples/xmp.py ../mnt -o allow_root Yep, this is how it should work. Csaba |
From: Nic J. F. <nfe...@ta...> - 2007-03-14 02:00:08
|
Csaba Henk <csa...@cr...> writes: > On 2007-03-12, Nic James Ferrier <nfe...@ta...> wrote: >> I'm trying to run a simple python fuse wrapper with allow_other and >> allow_root and it's not working. >> I can't find a single decent piece of documentation on how to do this, >> with an actual example of a command line. >> >> I've got the following debian packages: >> >> fuse-module-2.6.16-2-686 2.5.3-2+2.6.16-14 >> fuse-source 2.5.3-2 >> fuse-utils 2.6.3-1 >> libfuse2 2.5.3-4.1 >> python-fuse 2.5-5+b1 > > Only the devel version of the python bindings provides > fuselib-compatible option parsing... With the older version the > filesystems are left alone in this respect. They can implement fuselib > like parsing themselves, however, that's not done by xmp.py. Is there an example of the old style? I want to use the debian version specifically. > IIRC Debian still ships the oldie but properly released (and are waiting for > me to roll out a new release for the new stuff). > >> I have setup /etc/fuse.conf like so: >> >> user_allow_other >> > [...] >> and this: >> >> python /usr/share/doc/python-fuse/examples/xmp.py ../mnt -o allow_root > > Yep, this is how it should work. With the new version? I'd like to use the new version once it's in Debian. Hurry Up! -- Nic Ferrier ---------------------------------------------------------- Need a linux/java/python/web hacker? I'm in need of work! ---------------------------------------------------------- http://www.tapsellferrier.co.uk |
From: Csaba H. <csa...@cr...> - 2007-03-14 07:57:05
|
On 2007-03-14, Nic James Ferrier <nfe...@ta...> wrote: >> Only the devel version of the python bindings provides >> fuselib-compatible option parsing... With the older version the >> filesystems are left alone in this respect. They can implement fuselib >> like parsing themselves, however, that's not done by xmp.py. > > Is there an example of the old style? I want to use the debian version > specifically. There is no such thing as old style. I just meant that filesystems written with the help of fuse-py -- just like any other runnable program -- are free to parse their command line as they feel like, and among others, they can do it in the same way as fuselib does. Such a parsing routine is not provided by the stable/old version of fuse-py, so filesystems based on it are left alone in this respect. Some fs-es have put some work into doing something sensible with their command line though, take a look at, eg., wikipediafs or gmailfs. You can also see how parsing is made easy by the new API, see the main routines of the example fs-es in the CVS version at http://fuse.cvs.sourceforge.net/fuse/python/example/ They will parse their argv as you'd expect. > With the new version? > > I'd like to use the new version once it's in Debian. > > Hurry Up! Thanks for the encouragement, I try. Csaba |
From: Nic J. F. <nfe...@ta...> - 2007-03-18 22:24:40
|
Csaba Henk <csa...@cr...> writes: > You can also see how parsing is made easy by the new API, see the main > routines of the example fs-es in the CVS version at > > http://fuse.cvs.sourceforge.net/fuse/python/example/ > > They will parse their argv as you'd expect. > >> With the new version? >> >> I'd like to use the new version once it's in Debian. >> >> Hurry Up! > > Thanks for the encouragement, I try. Heh! Please! It would be good. I really like the look of the new API. Regarding the existing Debian version. I think I found a problem with it... It looks so silly though that I think I must have overlooked something. The fuse class constructor collects args passed to it or picks up on sys.argv. It puts the resulting details in self.optlist (or self.optdict). But the fuse.main() method does this to check whether a particular attribute has been set: if hasattr(self,'allow_other'): This is clearly going to fail! I patched the python source like this: --- /sudo:root@localhost:/usr/lib/python2.4/site-packages/fuse.py~ +++ /sudo:root@localhost:/usr/lib/python2.4/site-packages/fuse.py @@ -107,14 +107,21 @@ d = {'mountpoint': self.mountpoint} d['multithreaded'] = self.multithreaded - if hasattr( self, 'debug'): + + def has(obj, name): + if hasattr(obj, name): + return True + else: + return name in obj.optlist + + if has( self, 'debug'): d['lopts'] = 'debug'; k=[] - if hasattr(self,'allow_other'): + if has(self,'allow_other'): k.append('allow_other') - if hasattr(self,'kernel_cache'): + if has(self,'kernel_cache'): k.append('kernel_cache') if len(k): Diff finished. Sun Mar 18 22:23:48 2007 and that seems to work. Am I being dense or is this a real problem? -- Nic Ferrier ---------------------------------------------------------- Need a linux/java/python/web hacker? I'm in need of work! ---------------------------------------------------------- http://www.tapsellferrier.co.uk |
From: Csaba H. <csa...@cr...> - 2007-03-19 09:33:43
|
On Sun, Mar 18, 2007 at 10:25:30PM +0000, Nic James Ferrier wrote: > Regarding the existing Debian version. I think I found a problem with > it... It looks so silly though that I think I must have overlooked > something. > > The fuse class constructor collects args passed to it or picks up on > sys.argv. > > It puts the resulting details in self.optlist (or self.optdict). > > But the fuse.main() method does this to check whether a particular > attribute has been set: > > if hasattr(self,'allow_other'): > > This is clearly going to fail! Well, sure. In the old (stable) API, options get parsed somehow, and certain attributes are chechked somehow. And these two things are not connected. Now that's a well defined behaviour ableit not a blazingly convenient one, isn't it? I would not call it a bug it's rather an non matured design. > I patched the python source like this: Fine! Altough I think noone is in the position of merging this patch. I care about turning the devel branch into a release, the debian package maintainer cares about not changing interfaces (until a new relese). > Am I being dense or is this a real problem? Well, you can work this around even with the vanilla sources -- just do some private parsing to find out about 'allow_other', and set that attribute respectively. But of course, as long as you code the thing for private usage, it seems to be fine to streamline the code for yourself. But then why not just use the devel version, where it's all handled aptly?... Csaba |
From: Nic J. F. <nfe...@ta...> - 2007-03-19 14:34:43
|
Csaba Henk <csa...@cr...> writes: > Well, you can work this around even with the vanilla sources -- just do some > private parsing to find out about 'allow_other', and set that attribute > respectively. But of course, as long as you code the thing for private > usage, it seems to be fine to streamline the code for yourself. But then > why not just use the devel version, where it's all handled aptly?... As soon as it's in apt - I will! -- Nic Ferrier ---------------------------------------------------------- Need a linux/java/python/web hacker? I'm in need of work! ---------------------------------------------------------- http://www.tapsellferrier.co.uk |