> Thank you.
>
> So, I must use a copy (without setuid bit) for any setuid program that need
> access to a fuse-mounted directory.
Or use -oallow_other. It is quite safe on a single-user system.
Miklos

On 1/30/06, Miklos Szeredi <miklos@...> wrote:
>
> Uid checking became more strict in fuse-2.3. See the changelog entry
> for 2005-04-28:
>
> * Make checking of permission for other users more strict. Now
> the same privilege is required for the mount owner as for ptrace
> on the process performing the filesystem operation.
>
> This makes some setuid programs fail on fuse mounts.
Thank you.
So, I must use a copy (without setuid bit) for any setuid program that need
access to a fuse-mounted directory.
> It's there a way to tell fuse to use both ids, real and effective?
>
> I don't understand the question. What do you mean by "use"?
When checking rights, like:
granted =3D check(effective) || (real !=3D root && check(real));
but, now I see that its not a good ideea.
Bela

> 10q.
> You are right. Using "-o allow_root" or removing setuid bit on mutt_dotlock
> worked.
>
> But, why it's working with fuse 2.2.1?
Uid checking became more strict in fuse-2.3. See the changelog entry
for 2005-04-28:
* Make checking of permission for other users more strict. Now
the same privilege is required for the mount owner as for ptrace
on the process performing the filesystem operation.
This makes some setuid programs fail on fuse mounts.
> It's there a way to tell fuse to use both ids, real and effective?
I don't understand the question. What do you mean by "use"?
Miklos

On 2006-01-30, <belontzu@...> <belontzu@...> wrote:
> I have an unusual behaviour with mutt_dotlock.
> mutt_dotlock file => fail
> and
> strace mutt_dotlock file => succed
I have a guess.
Isn't mutt_dotlock setuid? By default, you are the only one who can use
the fs (so that you can't spy on other unsuspicious users I/O requests
via the fs daemon). A setuid process will be refused for this reason.
OTOH, stracing strips off the setuid bit, so then you are allowed to
enter the realm.
Did you try "-o allow_root" ?
Csaba

> Could this bug be related to this sshfs ChangeLog entry ?
> > 2005-10-28 Miklos Szeredi <miklos@...>
> >
> > * Add atomic create+open and ftruncate operation. This should fix
> > issues with 'cp' and other programs failing with "Permission
> > denied". To be effective, needs FUSE version 2.5 and kernel
> > version 2.6.15 (just a guess, since neither of them is released
> > yet).
No, it's a different bug, but they are both related to the atomicity
of file operations.
> Would this mean that there is no fix for kernel 2.4 ?
For the above problem, there isn't. But the rename workaround should
work fine on all platforms.
Miklos

> I found some strange and annoying behaviour when using sshfs.
> Overwriting an existing file with move seems impossible.
>
> when using a tiny test program called test.sh
> > #!/bin/sh
> > echo a > a
> > cp a b
> > mv a b
> > ls
> on ext3 i get:
> > $ ./test.sh
> > b test.sh
> on sshfs i get:
> > $ ./test.sh
> > mv: cannot move `a' to `b': Operation not permitted
> > a b test.sh
>
> I have this problem with fuse + sshfs from debian sarge as well as with
> current fuse (2.5.1) and sshfs (1.4) (debian kernel 2.4.27).
>
> This behaviour could be the reason that gedit can not save files,
> unless they are deleted (by hand) on the filesystem before.
>
> Any solutions ?
-oworkaround=rename
The resulting rename() operation is no longer atomic, like it is
defined in the standard.
For a proper fix the sftp protocol and sftp server would need to be
updated.
Miklos

Hi,
Could this bug be related to this sshfs ChangeLog entry ?
> 2005-10-28 Miklos Szeredi <miklos@...>
>=20
> * Add atomic create+open and ftruncate operation. This should fi=
x
> issues with 'cp' and other programs failing with "Permission
> denied". To be effective, needs FUSE version 2.5 and kernel
> version 2.6.15 (just a guess, since neither of them is released
> yet).
Would this mean that there is no fix for kernel 2.4 ?
Bye,
Wolfgang

Hi,
I found some strange and annoying behaviour when using sshfs.
Overwriting an existing file with move seems impossible.
when using a tiny test program called test.sh
> #!/bin/sh
> echo a > a
> cp a b
> mv a b
> ls
on ext3 i get:
> $ ./test.sh=20
> b test.sh
on sshfs i get:
> $ ./test.sh=20
> mv: cannot move `a' to `b': Operation not permitted
> a b test.sh
I have this problem with fuse + sshfs from debian sarge as well as with
current fuse (2.5.1) and sshfs (1.4) (debian kernel 2.4.27).
This behaviour could be the reason that gedit can not save files,
unless they are deleted (by hand) on the filesystem before.
Any solutions ?
Bye,
Wolfgang

Hi,
On 2006-01-28, Simon Barner <barner@...> wrote:
> I'd also be happy with a document describing the various FUSE APIs. I brows=
> ed
> your website, and did some research, but I could not find anything that wou=
> ld
> have been verbose enough for me...
My intention was to create one. I didn't really get there, but I
collected some real-life patches (just for the purpose of easing porting
to FreeBSD, but in fact, it's platform dependent, any API upgrader can
make use of them):
http://fuse4bsd.creo.hu/doc/html_chunked_out/Quickstart.html#hd001005
If you are porting Python bindings, you might be particularly interested in my
preliminary Perl binding API upgrade:
http://creo.hu/pipermail/fuse4bsd-devel/2006-January/000117.html
Not just because it's another scripting language, but also because these
seem to use the same API version (21).
I'd be happy to get feedback on the usability of these sample ABI
upgrade patches (my secret hope is hearing "they are damn very well
useable", because in that case I could forget about my planned "API
Changelog" without feeling guilty :)).
> +#define FUSE_USE_VERSION 25
> //@+others
> //@+node:includes
> +#include <sys/types.h>
> +#include <sys/param.h>
> +#include <sys/mount.h>
> #include <Python.h>
This seems to be OK.
> #include "fuse.h"
> #include <time.h>
> @@ -140,7 +144,8 @@
> goto out_decref;
> }
>=20
> - ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1));=09
> + /* XXX */
> + ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1), 0);=09
>=20
Fine, too.
> out_decref:
> Py_DECREF(o0);
> @@ -345,7 +350,7 @@
> fst->f_bavail =3D retvalues[3];
> fst->f_files =3D retvalues[4];
> fst->f_ffree =3D retvalues[5];
> - fst->f_namelen =3D retvalues[6];
> +// fst->f_namelen =3D retvalues[6];
>=20
Wrong. The signature of the statfs method has changed in API 25: instead
of struct statfs, it uses now struct statvfs (which is a standard).
Fields has to be filled as it's appropriate for statvfs, and you have to
take care about f_frsize, otherwise disc usage statistics will be
screwed up in FreeBSD (I guess giving it the same value as that of
f_bsize will do the job).
> ret =3D 0;
> =20
> @@ -378,7 +383,7 @@
> PyEval_AcquireLock();
> state =3D PyThreadState_New(interp);
> PyThreadState_Swap(state);
> - __fuse_process_cmd(f, cmd);
> + fuse_process_cmd(f, cmd);
> PyThreadState_Clear(state);
> PyThreadState_Swap(NULL);
I didn't know of this, someone could tell if it's appropriate this way?
Anyway, a bit lower there is a __fuse_loop_mt call, I suppose then that
one should be changed to fuse_loop_mt, too.
>=20
> fd =3D fuse_mount(mountpoint, kopts);
> - fuse =3D fuse_new(fd, lopts, &op);
> + fuse =3D fuse_new(fd, (struct fuse_args*)0, &op, sizeof (struct fuse_oper=
> ations));
The fuse_mount() call won't work out this way: now the second arg is not
just a plain string but a fuse_args structure. See the perl patch how
you can assemble such a thing without pain.
Other issues: I/O related methods have now a "struct fuse_file_info"
argument as well. Again, see perl patch.
In fact, I can't understand how you succeeded to get this compiled,
given the signature mismatches.
HTH.
Regards,
Csaba

Evan Langlois wrote:
> On Fri, 2006-01-27 at 13:58 +0100, Tomasz Chmielewski wrote:
>
>>Miklos Szeredi schrieb:
>>
>>>>Can I somehow mount a fuse filesystem in a way, that all
>>>>files/directories in it created by users will have their uids/gids?
>>>
>>>
>>>One way it to have a separate filesystem for each user's home, and run
>>>the filesystem daemon with the user's privileges.
>>
>>With users changing from time to time, it's not really an option.
>>Besides, it's an embedded system, I would rather use the RAM for
>>something else...
>
>
> Have you considered using an automount script? You'd only use the RAM
> when someone logs in and actually accesses that directory.
Actually, I contacted the LZOlayer_fs author, told him the hint I got
here ("set file ownership in your filesystem to fuse_get_context()->uid
and ->gid on file/directory creation"), and it looks that the issue is
fixed now :)
--
Tomasz Chmielewski
http://wpkg.org

On Fri, 2006-01-27 at 13:58 +0100, Tomasz Chmielewski wrote:
> Miklos Szeredi schrieb:
> >>Can I somehow mount a fuse filesystem in a way, that all
> >>files/directories in it created by users will have their uids/gids?
> >
> >
> > One way it to have a separate filesystem for each user's home, and run
> > the filesystem daemon with the user's privileges.
>
> With users changing from time to time, it's not really an option.
> Besides, it's an embedded system, I would rather use the RAM for
> something else...
Have you considered using an automount script? You'd only use the RAM
when someone logs in and actually accesses that directory.

Miklos Szeredi schrieb:
>>> - set file ownership in your filesystem to fuse_get_context()->uid
>>> and ->gid on file/directory creation
>>
>>This one I didn't understand.
>>Perhaps you mean changing that in LZOlayer_fs sources?
>
>
> Yes. FUSE cannot automatically change the ownership of the underlying
> files, it's up to the filesystem.
>
> Since the normal model for FUSE filesystems is the separate mounts for
> each user most filesystems simply lack the above feature.
OK, I see.
> Have you considered using some kind of automounting?
Not really.
It is to be a mount point used by Samba for keeping user profiles, so
automounting is not an option IMHO.
--
Tomasz Chmielewski
http://wpkg.org

> > - set file ownership in your filesystem to fuse_get_context()->uid
> > and ->gid on file/directory creation
>
> This one I didn't understand.
> Perhaps you mean changing that in LZOlayer_fs sources?
Yes. FUSE cannot automatically change the ownership of the underlying
files, it's up to the filesystem.
Since the normal model for FUSE filesystems is the separate mounts for
each user most filesystems simply lack the above feature.
Have you considered using some kind of automounting?
Miklos

Miklos Szeredi schrieb:
>>Can I somehow mount a fuse filesystem in a way, that all
>>files/directories in it created by users will have their uids/gids?
>
>
> One way it to have a separate filesystem for each user's home, and run
> the filesystem daemon with the user's privileges.
With users changing from time to time, it's not really an option.
Besides, it's an embedded system, I would rather use the RAM for
something else...
> The other way is to
>
> - use the "default_permissions" mount option to make the kernel
> check file permissions
I did, but it just doesn't work:
root# lzo_fs -s -o allow_other,default_permissions /mnt/3
root# cd /mnt/3
root# mkdir users
root# chmod 777 users
root# su tch
tch$ cd users
tch$ copy /bin/bash .
tch$ ls -l
-rwxr-xr-x 1 root root 749404 Jan 27 13:53 bash*
The file is owned by root, although I would like it to be owned by "tch"
user.
> - set file ownership in your filesystem to fuse_get_context()->uid
> and ->gid on file/directory creation
This one I didn't understand.
Perhaps you mean changing that in LZOlayer_fs sources?
BTW, I didn't write the filesystem, I merely used it.
--
Tomek

> Can I somehow mount a fuse filesystem in a way, that all
> files/directories in it created by users will have their uids/gids?
One way it to have a separate filesystem for each user's home, and run
the filesystem daemon with the user's privileges.
The other way is to
- use the "default_permissions" mount option to make the kernel
check file permissions
- set file ownership in your filesystem to fuse_get_context()->uid
and ->gid on file/directory creation
Miklos

I just used my first FUSE filesystem - LZOlayer_fs.
It's a compressed filesystem that I'm going to use on an embedded system
as a homedir for users.
What I noticed however, is that it seems impossible to use a fuse mount
point for more users, i.e., all files created in such a mount point are
always owned by one user.
An example:
We mount fuse/LZOlayer and go to the mount point:
root# ./lzo_fs -s -o allow_other /mnt/fuse
root# cd /mnt/fuse
root# mkdir test
root# chmod 1777 test
tch$ cd /mnt/fuse/test
tch$ mkdir test_dir
$ ls -l
total 4
drwxr-xr-x 2 root root 4096 Jan 26 22:24 test_dir/
Unfortunately, "test_dir" created by "tch" user is owned by "root".
On a normal filesystem I would expect it to be owned by "tch".
Because of this, I can't really use such a filesystem for /home, as all
files will be owned by root, and not the users.
Can I somehow mount a fuse filesystem in a way, that all
files/directories in it created by users will have their uids/gids?
I tried using different mount options, without luck.
--
Tomasz Chmielewski
http://wpkg.org

> >
> > Yup, this was recently fixed just before fuse-2.5.0 came out.
> >
> > * Order of request_end() and fuse_copy_finish() was wrong
> >
> > But you were the first to exploit this bug (as usual)
>
> Do I get a posthumous mention in the Changelog????
Sure thing:
* Order of request_end() and fuse_copy_finish() was wrong.
Posthumus note: Franco Broi managed to exploit this, though it
seemed quite impossible
> Works OK with 2.5.1
Great, thanks!
Miklos

On Fri, 2006-01-27 at 11:14 +0100, Miklos Szeredi wrote:
>
> Yup, this was recently fixed just before fuse-2.5.0 came out.
>
> * Order of request_end() and fuse_copy_finish() was wrong
>
> But you were the first to exploit this bug (as usual)
Do I get a posthumous mention in the Changelog????
> >
> > Easily reproducible, fails every time just by running find on the
> > client.
>
> Can you retest with a kernel module from fuse-2.5.*? No need to
> upgrade userspace, although it shouldn't hurt either.
Works OK with 2.5.1
Thanks.