Nabble - Fuse - Dev

Re: API breakage between 2.5.3 and 2.7.3

2008-09-06T07:41:43Z

On Saturday 2008-09-06 07:16, Conrad Meyer wrote:

>Hello list,
>
>Recently we ran into a little trouble building the Tux3 FUSE layer on
>different distros. Debian Etch has FUSE 2.5.3, and Fedora 9 has 2.7.3. Across
>these versions the fuse_main() macro grows another parameter. What's the
>expected workaround for C filesystems using FUSE that want to build on
>multiple distros?

For example autoconf that tests for the number of parameters.
See http://tinyurl.com/6k6hnm on how this is done.

Then again, FUSE 2.5.3 is almost 2 1/2 years old..

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

API breakage between 2.5.3 and 2.7.3

2008-09-06T04:16:48Z

Hello list,

Recently we ran into a little trouble building the Tux3 FUSE layer on
different distros. Debian Etch has FUSE 2.5.3, and Fedora 9 has 2.7.3. Across
these versions the fuse_main() macro grows another parameter. What's the
expected workaround for C filesystems using FUSE that want to build on
multiple distros?

Regards,
--
Conrad Meyer <cemeyer@...>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Creating a file with default Posix ACL

2008-09-04T10:12:42Z

Hi again,

I really cannot get the initial permissions right when there
is a default Posix ACL. I cannot overcome the umask having
been applied before the fuse create() method is called. I
mean the standard umask, not the fuse option with the same
name.

So I am asking again for help over this.

Here is a different example, with several umask values :

# get a clean environment
rm -rf trydir
# create a directory with a default ACL allowing all rwx
mkdir trydir
setfacl -m 'd:u::7,d:g::7,d:m::7,d:o::7' trydir
# check default ACL
getfacl trydir
# create files with several umasks
umask 0333
touch trydir/file333
ls -l trydir/file333
umask 0666
touch trydir/file666
ls -l trydir/file666
umask 0777
touch trydir/file777
ls -l trydir/file777
umask 000
touch trydir/file000
ls -l trydir/file000

This is the result on ext3 :

# file: trydir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx

-rw-rw-rw-+ 1 root root 0 2008-09-04 18:37 trydir/file333
-rw-rw-rw-+ 1 root root 0 2008-09-04 18:37 trydir/file666
-rw-rw-rw-+ 1 root root 0 2008-09-04 18:37 trydir/file777
-rw-rw-rw-+ 1 root root 0 2008-09-04 18:37 trydir/file000

This shows the umask should have no effect on the
initial mode, but with fuse (and ntfs-3g) I get :

# file: trydir
# owner: root
# group: root
user::rwx
user:root:---
group::---
mask::r-x
other::r-x
default:user::rwx
default:user:root:---
default:group::rwx
default:mask::rwx
default:other::rwx

-r--r--r--+ 1 root root 0 2008-09-04 18:37 trydir/file333
----------+ 1 root root 0 2008-09-04 18:37 trydir/file666
----------+ 1 root root 0 2008-09-04 18:37 trydir/file777
-rw-rw-rw-+ 1 root root 0 2008-09-04 18:37 trydir/file000

The modes are not correct, because the umask has
been applied to the requested mode before create()
is called.

Is there a way to overcome this ?

Thanks for any reply.

Jean-Pierre

Jean-Pierre André wrote:
> Hi,
>
> I am having difficulty in applying the correct initial mode
> and ACL when creating a file (or a directory), when the
> parent directory has a default Posix ACL.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-03T17:09:59Z

Eric W. Biederman wrote:
> Maintenance. What happens if I go 128bit, if I have some processes
> that are big endian and some that are little endian. Or if I have
> some processes that are running a completely different instruction
> set with a completely different ABI than other processes. Or
> perhaps different perhaps the processes is in a different network
> namespace than your filesystem and so it's arguments refer
> to something different entirely. Is it a userspace bug if userspace
> does not anticipate how the kernel will change in the future?

What I don't see is how anything becomes different whether that part
is implemented in kernel or not. For ioctls, only the implementing
code knows what the data structure should look like that's why we
can't handle 64/32 bit problems generically and has ->compat_ioctl
hook. To me, splitting it to two pieces looks like more maintenance
overhead than the other way around.

> If we don't look at ioctl as a set of system calls that should
> be put into an appropriate format for a filesystem we have
> a maintenance problem.
>
> If we don't have an interface clean enough we can push data
> out to a server on a remote machine have it processes the
> arguments and send the data back. We actually have failed
> to properly abstract the interface.

I don't think that's a possible goal in generic manner. We can't even
do that for read/writes. At least not at FUSE's level. We need
higher abstraction for that. e.g. /dev/oss via CUSE, ioctl specified
machine endian 16bit format. Supporting that in the way you described
would require a lot of logic in the kernel and I don't really see any
benefit over, say, forward the sound via pulseaudio after getting it
to userland. I don't think the problem can or should be solved at
FUSE interface level.

>> Well, kernel stub kind of beats a lot of benefits of FUSE - no
>> specific kernel dependencies, easy development and distribution,
>> etc...
>
> Of course FUSE has specific kernel dependencies. It depends
> on the implementation of fusefs in the kernel to talk to it.
> The reason you don't need a specific kernel today is that
> the kernel dependencies are well defined. You are talking
> about using a very poorly defined interface to talk to the
> filesystem. At which point it would be better to open
> a separate channel and talk to the filsystem directly.

The difference is that FUSE servers depend on FUSE and each server
doesn't require separate new pieces to get working and ioctl is poorly
defined by nature.

> Being able to add a kernel system call (ioctl) with no review is a
> total maintenance disaster. It is impossible to maintain because
> there is not a process to even discover what is going on.

How about adding whole FSes w/o a review? That's the whole point of
FUSE. Seriously, there are infinite number of ways to break the
regular defined filesystem semantics using FUSE. FUSE should provide
mechanism and protects against certain fundamental things. It can't
enforce correct semantics on everything.

> We have to have a kernel stub to support other system calls
> and I don't see why individual ioctls should be different.
>
> If you want to support forwards compatibility reserving
> some ioctl numbers and saying these numbers will always
> be parsed this way. Which would allow you to write
> a common stub that can be implemented before the ioctls
> are implemented.

ioctls is most likely to be used to emulate legacy or proprietary
devices. If you're worried about filesystems abusing it, maybe the
solution is to only allow CUSE to use ioctls but I really don't see
what the problem is here. If the userland FS server wants to shoot
itself in the foot, it's not really the kernel's problem.

> If you really don't want new kernel dependencies you can hook up to
> the process via ptrace and intercept the ioctls before they even get
> to the kernel. If you can open /proc/<pid>/mem you have the rights
> to ptrace the process.

Aieee.. The same goes for the whole FUSE.

Thanks.

--
tejun

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-03T14:51:10Z

Tejun Heo <tj@...> writes:

> Eric W. Biederman wrote:
>> I really think that if an ioctl is passing through the kernel we
>> should know how to parse and understand it's options. Otherwise
>> we won't have the option of doing backwards compatibility when something
>> changes, like we can with the 32->64bit ioctls.
>
> There's no reason 32->64bit can't be handled in userland? What's the
> difference?

Maintenance. What happens if I go 128bit, if I have some processes
that are big endian and some that are little endian. Or if I have
some processes that are running a completely different instruction
set with a completely different ABI than other processes. Or
perhaps different perhaps the processes is in a different network
namespace than your filesystem and so it's arguments refer
to something different entirely. Is it a userspace bug if userspace
does not anticipate how the kernel will change in the future?

If we don't look at ioctl as a set of system calls that should
be put into an appropriate format for a filesystem we have
a maintenance problem.

If we don't have an interface clean enough we can push data
out to a server on a remote machine have it processes the
arguments and send the data back. We actually have failed
to properly abstract the interface.

>> That seems to imply that you need a stub in the kernel to handle
>> really weird ioctls.
>>
>> The upside is that because you know what the inputs and outputs are
>> and where the inputs and output are you can support that ioctl well
>> into the future, and you can do it with an unprivileged file
>> system server.
>
> Well, kernel stub kind of beats a lot of benefits of FUSE - no
> specific kernel dependencies, easy development and distribution,
> etc...

Of course FUSE has specific kernel dependencies. It depends
on the implementation of fusefs in the kernel to talk to it.
The reason you don't need a specific kernel today is that
the kernel dependencies are well defined. You are talking
about using a very poorly defined interface to talk to the
filesystem. At which point it would be better to open
a separate channel and talk to the filsystem directly.

Being able to add a kernel system call (ioctl) with no review is a
total maintenance disaster. It is impossible to maintain because
there is not a process to even discover what is going on.

We have to have a kernel stub to support other system calls
and I don't see why individual ioctls should be different.

If you want to support forwards compatibility reserving
some ioctl numbers and saying these numbers will always
be parsed this way. Which would allow you to write
a common stub that can be implemented before the ioctls
are implemented.

If you really don't want new kernel dependencies you can hook up to
the process via ptrace and intercept the ioctls before they even get
to the kernel. If you can open /proc/<pid>/mem you have the rights
to ptrace the process.

Eric

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-03T07:40:24Z

Eric W. Biederman wrote:
> I really think that if an ioctl is passing through the kernel we
> should know how to parse and understand it's options. Otherwise
> we won't have the option of doing backwards compatibility when something
> changes, like we can with the 32->64bit ioctls.

There's no reason 32->64bit can't be handled in userland? What's the
difference?

> That seems to imply that you need a stub in the kernel to handle
> really weird ioctls.
>
> The upside is that because you know what the inputs and outputs are
> and where the inputs and output are you can support that ioctl well
> into the future, and you can do it with an unprivileged file
> system server.

Well, kernel stub kind of beats a lot of benefits of FUSE - no
specific kernel dependencies, easy development and distribution,
etc...

Thanks.

--
tejun

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-03T07:32:22Z

Tejun Heo <tj@...> writes:

> Hello,
>
> Miklos Szeredi wrote:
>>> So why not just only support well defined ioctls and serialize them
>>> in the kernel and allow the receiving process to deserialize them?
>>
>> I'd like the idea of limiting to well behaved ioctls, but Tejun
>> doesn't...
>
> I'm not dead against it. I'm just a bit more inclined to my
> implementation (naturally), which means if you're dead against the
> current implementation, supporting only the proper ones definitely is
> an option, but comparing the pros and cons, I'm not quite convinced
> yet.

I really think that if an ioctl is passing through the kernel we
should know how to parse and understand it's options. Otherwise
we won't have the option of doing backwards compatibility when something
changes, like we can with the 32->64bit ioctls.

That seems to imply that you need a stub in the kernel to handle
really weird ioctls.

The upside is that because you know what the inputs and outputs are
and where the inputs and output are you can support that ioctl well
into the future, and you can do it with an unprivileged file
system server.

Eric

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-02T15:07:30Z

On Tue, 2 Sep 2008, Maxim Levitsky wrote:

> Szabolcs Szakacsits wrote:
> > On Mon, 1 Sep 2008, Maxim Levitsky wrote:
> >> (And does full path walk on each syscall)?
> >
> > The stable release, yes. But it was never the intention to stay this way
> > and we are working on the migration for over a year. Depending on quite
> > many things, our measured speedup is 100-200%. But this is really file
> > system and implementation specific.
>
> This is a lot, imagine the same on top of cd/dvd device that has very slow
> seek speeds...

If the cd/dvd device has a buffer cache, what I suspect, then the two are
often orthogonal.

The above 100-200% is only for NTFS which has an exceptionally big
computation overhead. Once when I was testing the low-level vs high-level
performance difference with highly optimized ram file systems then the
difference was only 10-30%. But this percentage really depends on many
things.

The computation (and the above 100-200% improvement) is absolutely
neglectable many times compared to seek performance (amount and costs).

Below is the result of compilebench (developed by/for btrfs) which
simulates unpacking the kernel tarball 30 times in different directories:

Runtime (s)
-----------
btrfs unstable, no dup 168
btrfs unstable 197
ext4 2.6.26 245
nilfs2 2nd+ runs 287
ntfs-3g unstable 370
ext3 559
xfs nobarrier 562
reiserfs 595
xfs nobarrier, ncq, wc off 1070
nilfs2 1st run 3719
xfs 3786

btrfs, ext4, nilfs are all designed to optimize out seeks.

The tested ntfs-3g is not optimized, uses the high-level FUSE API and it's
still far faster than any current stable Linux file system, at least in
the above test.

How is it possible?

I suspect it's because the DEC engineers hired by Microsoft in the
beginning of the 90's already have learnt the hard way how important seek
elimination and NTFS was designed accordingly, based on the Files-11 file
system from PDP-11.

Optimizing out as many seeks as possible is highly crucial for performance,
though this is changing with the spreading of SSD.

Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [ANNOUNCE] OSS Proxy using CUSE

2008-09-02T08:25:18Z

Hi!

> > So, after all the fuss, here's the state-of-the-art standard-compliant
> > cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
> >
> > http://userweb.kernel.org/~tj/ossp/
> >
> > It works pretty well here. :-)
>
> Sorry for being destructive, but 6 years after ALSA went into the
> kernel we are slightly approaching the point where all applications
> support ALSA.

Did ALSA reach a point where you can support new cards by just
updating the kernel?

I kind of like /dev/dsp interface... and don't see why simple sound
apps should be linked to libalsa... I used to record and play sounds
from shell by cat /dev/dsp...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Creating a file with default Posix ACL

2008-09-02T07:18:05Z

Oops,

Of course in that situation, the mode and umask should
be ignored altogether and replaced by the default ACL,
so there is no problem.

Sorry for the disturbance.

Regards

Jean-Pierre

Jean-Pierre André wrote:

> Hi,
>
> I am having difficulty in applying the correct initial mode
> and ACL when creating a file (or a directory), when the
> parent directory has a default Posix ACL.
>
> The fuse create() method receives an initial mode with
> the umask applied. Now, according to the Posix draft, the
> umask should be applied when there is no default ACL,
> but it should not when there is one.
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Creating a file with default Posix ACL

2008-09-02T05:44:52Z

Hi,

I am having difficulty in applying the correct initial mode
and ACL when creating a file (or a directory), when the
parent directory has a default Posix ACL.

The fuse create() method receives an initial mode with
the umask applied. Now, according to the Posix draft, the
umask should be applied when there is no default ACL,
but it should not when there is one.

Here is an example :

# get a clean environment
rm -rf trydir
# create a directory with a default ACL
mkdir trydir
setfacl -m 'd:u::wx,d:g:1000:x,d:g::wx,d:o::wx,d:m::rwx' trydir
# set umask to 077 and create a file
umask 077
touch trydir/tryfile
# display its mode and ACL
/bin/ls -l trydir/tryfile
getfacl trydir/tryfile

And this is the expected result (tried on ext3) :

--w-rw--w-+ 1 linux linux 0 2008-09-02 13:03 trydir/tryfile
# file: trydir/tryfile
# owner: linux
# group: linux
user::-w-
group::-wx #effective:-w-
group:1000:--x #effective:---
mask::rw-
other::-w-

But, with fuse, the mode given to create() is 0600
because the umask has been applied, and I cannot
get the initial create() mode. I experience the same
behavior with mkdir

This cannot be a fuse option, as the behaviour
depends on the parent directory setting. In the
create process, I do not see anybody querying the
default ACL to decide over the umask.

Is there a way to get it around ?

Thanks for any help.

Regards

Jean-Pierre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T14:37:32Z

Szabolcs Szakacsits wrote:

> On Mon, 1 Sep 2008, Maxim Levitsky wrote:
>> What are disadvantages of using fuse low level operations?
>> Why ntfs-3g doesn't use them?
>
> The Microsoft NTFS driver is over 500,000 lines of code (something almost
> like the size of all the 60+ in-kernel Linux file system altogether) and
> first we were solely focusing to implement about 10% of this subset to be
> as functional as possible for reliable interoperability (that's about 15-20
> man-year work -- though we work on this only for 13 years).
>
>> (And does full path walk on each syscall)?
>
> The stable release, yes. But it was never the intention to stay this way
> and we are working on the migration for over a year. Depending on quite
> many things, our measured speedup is 100-200%. But this is really file
> system and implementation specific.

This is a lot, imagine the same on top of cd/dvd device that has very slow
seek speeds...

>
> We also always tend to focus on the biggest bottlenecks, for instance FUSE
> big write support improved write performance by 800-1000%, thanks to Nick
> Piggin and Miklos.
>
>> Are they less portable/stable?
>
> The high-level API do use the low-level API, so the low-level should be at
> least as stable as the high-level (I think the FUSE layering is fantastic
> and actually it's quite efficient).
>
> I don't know sure its portability, usually they are very similar. We have
> found that Linux FUSE is the most reliable (no known problem). The OS X,
> FreeBSD and Solaris FUSE ports have problems but they seem to be in the
> kernels. No news from NetBSD (it either works fine or not many ntfs-3g
> users).
>
> I hope these explain and help somewhat ...
>
> Regards,
> Szaka
>

Thanks a lot, I have no more questions now.

Best regards,
Maxim Levitsky

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T13:46:30Z

On Mon, Sep 1, 2008 at 4:51 PM, Szabolcs Szakacsits <szaka@...> wrote:
> I don't know sure its portability, usually they are very similar. We have
> found that Linux FUSE is the most reliable (no known problem). The OS X,
> FreeBSD and Solaris FUSE ports have problems but they seem to be in the
> kernels. No news from NetBSD (it either works fine or not many ntfs-3g
> users).

NetBSD has it's own filesystem in userspace mechanism called PUFFS and
a library called librefuse that translates fuse api into puffs api. I
am not sure,
but I think that this interface is compatible only with the FUSE high level
interface.

Details: http://www.netbsd.org/docs/puffs/

Best Regards

--
Luis Otavio de Colla Furquim
Não alimente os pingos
Don't feed the tribbles
http://www.furquim.org/chironfs/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T12:51:56Z

On Mon, 1 Sep 2008, Maxim Levitsky wrote:
> What are disadvantages of using fuse low level operations?
> Why ntfs-3g doesn't use them?

The Microsoft NTFS driver is over 500,000 lines of code (something almost
like the size of all the 60+ in-kernel Linux file system altogether) and
first we were solely focusing to implement about 10% of this subset to be
as functional as possible for reliable interoperability (that's about 15-20
man-year work -- though we work on this only for 13 years).

> (And does full path walk on each syscall)?

The stable release, yes. But it was never the intention to stay this way
and we are working on the migration for over a year. Depending on quite
many things, our measured speedup is 100-200%. But this is really file
system and implementation specific.

We also always tend to focus on the biggest bottlenecks, for instance FUSE
big write support improved write performance by 800-1000%, thanks to Nick
Piggin and Miklos.

> Are they less portable/stable?

The high-level API do use the low-level API, so the low-level should be at
least as stable as the high-level (I think the FUSE layering is fantastic
and actually it's quite efficient).

I don't know sure its portability, usually they are very similar. We have
found that Linux FUSE is the most reliable (no known problem). The OS X,
FreeBSD and Solaris FUSE ports have problems but they seem to be in the
kernels. No news from NetBSD (it either works fine or not many ntfs-3g
users).

I hope these explain and help somewhat ...

Regards,
Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T11:46:09Z

Maxim Levitsky wrote:

> John Muir wrote:
>> On 1-Sep-08, at 12:04 PM, Maxim Levitsky wrote:
>>> This is fundamental feature/bug of fuse, it doesn't have the concept
>>> of inodes, and instead just forwards the syscalls
>>> to filesystem application, and I agree that for most "virtual"
>>> filesystems this is the right thing to do.
>>> Thus I have ether to have disk wide cache, and do full walk each
>>> time, or cache the file tree.
>>
>> Have a look at more of the FUSE library interfaces before you complain
>> about fundamental bugs. The low-level interface (fuse_lowlevel.h)
>> might be interesting to you.
>>
>> Regards,
>>
>> John.
>>
>
> Sorry :-)
>
> This is exactly what I need, I didn't want to offend anyone.
>
> Best regards,
> Maxim Levitsky

A follow on question:

What are disadvantages of using fuse low level operations?
Why ntfs-3g doesn't use them? (And does full path walk on each syscall)?
Are they less portable/stable?

Best regards,
Maxim Levitsky

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T09:36:00Z

John Muir wrote:

> On 1-Sep-08, at 12:04 PM, Maxim Levitsky wrote:
>> This is fundamental feature/bug of fuse, it doesn't have the concept
>> of inodes, and instead just forwards the syscalls
>> to filesystem application, and I agree that for most "virtual"
>> filesystems this is the right thing to do.
>> Thus I have ether to have disk wide cache, and do full walk each time,
>> or cache the file tree.
>
> Have a look at more of the FUSE library interfaces before you complain
> about fundamental bugs. The low-level interface (fuse_lowlevel.h) might
> be interesting to you.
>
> Regards,
>
> John.
>

Sorry :-)

This is exactly what I need, I didn't want to offend anyone.

Best regards,
Maxim Levitsky

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T09:14:21Z

On 1-Sep-08, at 12:04 PM, Maxim Levitsky wrote:
> This is fundamental feature/bug of fuse, it doesn't have the concept
> of inodes, and instead just forwards the syscalls
> to filesystem application, and I agree that for most "virtual"
> filesystems this is the right thing to do.
> Thus I have ether to have disk wide cache, and do full walk each
> time, or cache the file tree.

Have a look at more of the FUSE library interfaces before you complain
about fundamental bugs. The low-level interface (fuse_lowlevel.h)
might be interesting to you.

Regards,

John.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T09:04:30Z

Miklos Szeredi wrote:

> On Fri, 29 Aug 2008, Maxim Levitsky wrote:
>> Just one question, if I disable vfs caching (pagecache for inodes),
>> how much it will hit performance?
>
> It depends on many factors. If you are using direct_io to turn off
> caching, that will mean no readahead, so there will be a performance
> hit from the context switch latency, especially for small reads.
>
>> (I want to cache quite a lot of information, so I don't want to
>> waste memory that much)

Let me explain this.

I did a look at fuse operations, and I noticed that, all operations that
work on an inode like adding/deleting,renaming directory entries, receive
absolute path to the file, and filesystem is left to walk the path again and again, determine
the inode, and work on it. Thus a dcache like cache is a must, especially since I will talk to device
using SCSI commands, thus bypass last resort cache (block device cache) (according to ntfs-3g, they don't cache the inodes/directory tree,
but they rely on block device cache)

This is fundamental feature/bug of fuse, it doesn't have the concept of inodes, and instead just forwards the syscalls
to filesystem application, and I agree that for most "virtual" filesystems this is the right thing to do.
Thus I have ether to have disk wide cache, and do full walk each time, or cache the file tree.

Why to cache data, well now I understand that I don't need that, but for some extent filesystem might benefit.
To write data on packet - formatted disks, I have to write in in 32k/64k chunks, but read sector size is just 2K
thus by caching the data I might save some seeks.

Best regards,
Maxim Levitsky

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-01T05:03:01Z

Hello,

Miklos Szeredi wrote:
>> So why not just only support well defined ioctls and serialize them
>> in the kernel and allow the receiving process to deserialize them?
>
> I'd like the idea of limiting to well behaved ioctls, but Tejun
> doesn't...

I'm not dead against it. I'm just a bit more inclined to my
implementation (naturally), which means if you're dead against the
current implementation, supporting only the proper ones definitely is
an option, but comparing the pros and cons, I'm not quite convinced
yet.

Thanks.

--
tejun

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCH 5/7] FUSE: implement ioctl support

2008-09-01T04:57:58Z

On Fri, 29 Aug 2008, ebiederm@... (Eric W. Biederman)

> Tejun Heo <tj@...> writes:
> > The FUSE server gets task->pid. IIUC, if the FUSE server is not in a
> > container, task->pid should work fine whether the caller is in
> > container or not, right? And if the FUSE server is in a container,
> > it's hell lot more complex and FUSE may have to map task->pid to what
> > FUSE server would know if possible?
>
> Implementation wise it is not too bad.
>
> FUSE ----------------
> pid = get_pid(task_tid(current))
> ^ |
> | | kernel
> pid_vnr(pid)

Ahh, thanks. I'll need to fix this up then, regardless of any ioctl
issues, so that the tid supplied to the userspace filesystem actually
makes sense in a containerized environment.

> However it is a largely an insane idea.
> - Write is not implemented for /proc/PID/task/TID/mem

Mmm, that does pose a bit of a problem :)

> - It would be better if the kernel handed you back a file descriptor
> to the other process memory rather than you having to generate one.

Yep, that could be done...

> - To access /proc/PID/task/TID/mem you need to have CAP_PTRACE.

Yes, but access to the other process's address space requires some
sort of privilege anyway. It would not do to have an unprivileged
process peek at arbitrary addresses in the other process's memory, and
that is exactly what generic ioctl support requires.

> - This seems to allow for random ioctls. With the compat_ioctl
> thing we have largely stomped on that idea. So you should only need
> to deal with well defined ioctls. At which point why do you need to
> directly access the memory of another process.
>
> So why not just only support well defined ioctls and serialize them
> in the kernel and allow the receiving process to deserialize them?

I'd like the idea of limiting to well behaved ioctls, but Tejun
doesn't...

> That would allow all of this to happen with a non-privileged server
> which makes the functionality much more useful.

There's still a security issue, because we cannot verify *if* a
particular ioctl is indeed well behaved: only the application and the
driver knows that, and the application cannot tell us (ioctl interface
is broken, broken, broken), and we don't trust the server.

Thanks,
Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: Is fuse suitable for UDF packet writing implementation?

2008-09-01T04:23:02Z

On Fri, 29 Aug 2008, Maxim Levitsky wrote:
> Just one question, if I disable vfs caching (pagecache for inodes),
> how much it will hit performance?

It depends on many factors. If you are using direct_io to turn off
caching, that will mean no readahead, so there will be a performance
hit from the context switch latency, especially for small reads.

> (I want to cache quite a lot of information, so I don't want to
> waste memory that much)

Why do you need to cache data in userspace?

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCHSET] CUSE: implement CUSE

2008-09-01T00:38:45Z

On Mon, Sep 01, 2008 at 09:20:19AM +0200, Goswin von Brederlow <goswin-v-b@...> wrote:

> Mike Hommey <mh@...> writes:
>
> > On Sat, Aug 30, 2008 at 02:30:32PM +0200, Tejun Heo wrote:
> >> Yeah, compared to loopback over FUSE, anything would have less
> >> problem. :-) I don't know much about nbd but it's pretty much solving
> >> the same problem so I think it's logical to extend nbd including
> >> giving it a new transport if necessary? Or is there something
> >> fundamentally better when it's done via FUSE?
> >
> > My gutt feeling is that it would have less overhead when done via FUSE
> > than through nbd, but that could be wrong.
> >
> > Mike
>
> What I would hope is that BUSE would add some zero copy transport in
> there. A way to just redirect the BIOs from the BUSE device to other
> block devices without copying the data around.
>
> But maybe BUSE is a bad name for that. That would be more a DUSE -
> Device mapper in USEr space.

That already exists. http://wiki.xensource.com/xenwiki/DmUserspace

Mike

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: [PATCHSET] CUSE: implement CUSE

2008-09-01T00:20:19Z

Mike Hommey <mh@...> writes:

> On Sat, Aug 30, 2008 at 02:30:32PM +0200, Tejun Heo wrote:
>> Yeah, compared to loopback over FUSE, anything would have less
>> problem. :-) I don't know much about nbd but it's pretty much solving
>> the same problem so I think it's logical to extend nbd including
>> giving it a new transport if necessary? Or is there something
>> fundamentally better when it's done via FUSE?
>
> My gutt feeling is that it would have less overhead when done via FUSE
> than through nbd, but that could be wrong.
>
> Mike

What I would hope is that BUSE would add some zero copy transport in
there. A way to just redirect the BIOs from the BUSE device to other
block devices without copying the data around.

But maybe BUSE is a bad name for that. That would be more a DUSE -
Device mapper in USEr space.

MfG
Goswin.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

questions about flock and posix lock support in FUSE

2008-08-31T22:33:30Z

Hello,

I am finding there is a flag (FUSE_LK_FLOCK) in fuse kernel module
used to differentiate posix lock and flock.
This flag is recorded in the struct fuse_lk_in.lk_flags.

But this info is discarded in fuse use lib (in do_setlk_common), so at
last when the lock request info was passed to the user space
filesystem, we can't differentiate it's a posix lock or a flock.

Is it on purpose?

Thanks,
Hong

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: linux kernel 2.6.27-rc5 and fuse gives no LOOKUP_ACCESS

2008-08-31T13:26:51Z

Hi,

Am Sonntag, den 31.08.2008, 18:23 +0300 schrieb Szabolcs Szakacsits:

> On Sun, 31 Aug 2008, Lars Oliver Hansen wrote:
>
> > I tried to make fuse 2.7.4 in order to add it as a kernel module because
> > I didn't choose it in the kernel configuration of kernel 2.6.27-rc5 and
> > I need it to access my external USB harddisk and I didn't want to
> > recompile the kernel (I use Ubuntu 8.04 and compiled a custom kernel. My
> > external harddisk has a NTFS file system and I enabled usbstorage and
> > NTFS support in the custom kernel. dmesg output looks identical with
> > regard to usb storage to Ubuntus generic kernel and the external
> > harddisk worked under Ubuntu, accessing the location "external harddisk"
> > with the custom kernel yields an error "fuse missing").
> >
> > Make gives an error about a missing LOOKUP_ACCESS declaration. I read in
> > a previous posting to this mailing list that it is supposed to be in
> > linux/namei.h.
> >
> > Linux kernel 2.6.27-rc5 namei.h doesn't have a LOOKUP_ACCESS
> > declaration. (it has different LOOKUP_xxx declarations).
> >
> > Can you help here?
>
> Your only option (which is far the best [performance, functionality] than
> anything else) is FUSE from the 2.6.27 kernel.
>
> No need for kernel NTFS support which may or may not cause unexpected
> problems for you.
>
> Szaka
>

Thanks for your advice. I configured 2.6.27-rc5 to use FUSE and disabled
NTFS support. I recompiled. (After all only 10 minutes waiting.)
My external harddisk is accessible now with the new kernel!

Thanks again!

Lars
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T12:44:42Z

On Sun, 31 Aug 2008, Werner Baumann wrote:

> From ntfs-3g man-page:
> it can handle special files like symbolic links, devices, and FIFOs
> ...
> By default ... everybody has full read, write, execution and directory
> browsing permissions.
>
> From http://pagesperso-orange.fr/b.andre/security.html:
> Special ACL configurations are also used to represent the sticky, setuid
> and setgid flags which have no real equivalent in Windows.
>
> Compare to this restriction in doc/kernel.txt:
> The solution is not to allow opening device files and ignore
> setuid and setgid bits when executing programs. To ensure this
> fusermount always adds "nosuid" and "nodev" to the mount options
> for non-privileged mounts.
>
> Nothing dropped? Or do I misunderstand your documentation?

Ntfs-3g can be used with both fuse user space and fuse-lite. Both add
unconditionally the "nosuid" and "nodev" option for unprivileged mounts.
For fuse-lite it's at mount.c:217:

if (getuid())
mo.flags = MS_NOSUID | MS_NODEV;

> > Please provide a specific exploit. Thank you.
>
> No I will not, it is not the kind of thing I am trained in. Are you sure
> that is impossible to create a windows partition that, when mounted with
> ntfs-3g, contains executable files, owned by root and setuid? According
> to http://pagesperso-orange.fr/b.andre/security.html and the man page, I
> can't see any real obstacle.

Nosuid and nodev should be enforced by the kernel via the mount options
which are always unconditionally added for unprivileged mounts.

Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T11:48:46Z

Szabolcs Szakacsits wrote:

> On Sun, 31 Aug 2008, Werner Baumann wrote:
>
>> I am concerned about security implications of uncontrolled usermounts
>> and measures to make them secure. Something like you find in
>> doc/kernel.txt in the fuse-package.
>>
>> In the ntfs-3g man page I find this:
>>
>> ntfs-3g is an NTFS driver, which can create, remove, rename, move files,
>> directories, hard links, and streams; it can read and write files,
>> including streams and sparse files; it can handle special files like
>> symbolic links, devices, and FIFOs; moreover it can also read
>> transparently compressed files. ... Access Handling and Security By
>> default, files and directories are owned by the effective user and group
>> of the mounting process and everybody has full read, write, execution and
>> directory browsing permissions. If you want to use permissions handling
>> then use the uid and/or the gid options together with the umask, or fmask
>> and dmask options.
>>
>> Compared with fuse, it looks like you dropped every security related
>> restriction.
>
> I checked doc/kernel.txt and I can't figure out what you mean we dropped.
>

From ntfs-3g man-page:
it can handle special files like symbolic links, devices, and FIFOs
...
By default ... everybody has full read, write, execution and directory
browsing permissions.

From http://pagesperso-orange.fr/b.andre/security.html:
Special ACL configurations are also used to represent the sticky, setuid
and setgid flags which have no real equivalent in Windows.

Compare to this restriction in doc/kernel.txt:
The solution is not to allow opening device files and ignore
setuid and setgid bits when executing programs. To ensure this
fusermount always adds "nosuid" and "nodev" to the mount options
for non-privileged mounts.

Nothing dropped? Or do I misunderstand your documentation?

> Please provide a specific exploit. Thank you.
>
No I will not, it is not the kind of thing I am trained in. Are you sure
that is impossible to create a windows partition that, when mounted with
ntfs-3g, contains executable files, owned by root and setuid? According
to http://pagesperso-orange.fr/b.andre/security.html and the man page, I
can't see any real obstacle.

Cheers
Werner

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T11:06:17Z

On Sun, 31 Aug 2008, Werner Baumann wrote:

> I am concerned about security implications of uncontrolled usermounts
> and measures to make them secure. Something like you find in
> doc/kernel.txt in the fuse-package.
>
> In the ntfs-3g man page I find this:
>
> ntfs-3g is an NTFS driver, which can create, remove, rename, move files,
> directories, hard links, and streams; it can read and write files,
> including streams and sparse files; it can handle special files like
> symbolic links, devices, and FIFOs; moreover it can also read
> transparently compressed files. ... Access Handling and Security By
> default, files and directories are owned by the effective user and group
> of the mounting process and everybody has full read, write, execution and
> directory browsing permissions. If you want to use permissions handling
> then use the uid and/or the gid options together with the umask, or fmask
> and dmask options.
>
> Compared with fuse, it looks like you dropped every security related
> restriction.

I checked doc/kernel.txt and I can't figure out what you mean we dropped.

Please provide a specific exploit. Thank you.

Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T10:03:02Z

Szabolcs Szakacsits wrote:

> On Sun, 31 Aug 2008, Werner Baumann wrote:
>> Szabolcs Szakacsits wrote:
>>>> What is the "bunch of things" to make 'mount -t ntfs-3g ...' work for an
>>>> unprivileged user?
>>> http://ntfs-3g.org/support.html#useroption
>>>
>> It would like not only to know "what to do", but "how it works". The
>> mount(8)-program executes this code, immediately after parsing the
>> command line:
>>
>> if (getuid () != geteuid ()) {
>> suid = 1;
>> if (types || options || readwrite || nomtab || mount_all ||
>> fake || mounttype || (argc + specseen) != 1)
>> die (EX_USAGE, _("mount: only root can do that"));
>> }
>>
>> - mount(8) usually is setuid root (otherwise unprivileged mounts
>> *with* an entry in fstab would not work)
>> - when the "-t" option is present on the command line, "types" is
>> not NULL
>> - both conditions are true and mount will terminate.
>>
>> *How* do you get around this?
>
> Ok, so there are mounts which don't support it yet. This only makes the
> current unprivileged mount situation more unfortunate ...
>

I refer to the mount and umount-program from
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
Please tell me your source. It looks like you are using a patched
version of mount. But the people who patched mount to allow unprivileged
mounts without entry in fstab "forgot" to apply a corresponding patch to
umount. But they surely carefully examined all the other, not that
obvious, implications of their patch?

> Full ownership and permission support is provided separately which is
> documented in the first paragraph of the ntfs-3g home page and accessible
> at
>
> http://pagesperso-orange.fr/b.andre/security.html
>
This link is about mapping ntfs ownership and permissions to unix
ownership and permissions.
I am concerned about security implications of uncontrolled usermounts
and measures to make them secure. Something like you find in
doc/kernel.txt in the fuse-package.

In the ntfs-3g man page I find this:

ntfs-3g is an NTFS driver, which can
create, remove, rename, move files, directories, hard links, and
streams; it can read and write files, including
streams and sparse files; it can handle special files like
symbolic links, devices, and FIFOs; moreover it can also read
transparently compressed files.
...
Access Handling and Security
By default, files and directories are owned by the effective
user and group of the mounting process and everybody has
full read, write, execution and directory browsing permissions.
If you want to use permissions handling then use the
uid and/or the gid options together with the
umask, or fmask and dmask options.

Compared with fuse, it looks like you dropped every security related
restriction.

Cheers
Werner

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: linux kernel 2.6.27-rc5 and fuse gives no LOOKUP_ACCESS

2008-08-31T08:23:16Z

On Sun, 31 Aug 2008, Lars Oliver Hansen wrote:

> I tried to make fuse 2.7.4 in order to add it as a kernel module because
> I didn't choose it in the kernel configuration of kernel 2.6.27-rc5 and
> I need it to access my external USB harddisk and I didn't want to
> recompile the kernel (I use Ubuntu 8.04 and compiled a custom kernel. My
> external harddisk has a NTFS file system and I enabled usbstorage and
> NTFS support in the custom kernel. dmesg output looks identical with
> regard to usb storage to Ubuntus generic kernel and the external
> harddisk worked under Ubuntu, accessing the location "external harddisk"
> with the custom kernel yields an error "fuse missing").
>
> Make gives an error about a missing LOOKUP_ACCESS declaration. I read in
> a previous posting to this mailing list that it is supposed to be in
> linux/namei.h.
>
> Linux kernel 2.6.27-rc5 namei.h doesn't have a LOOKUP_ACCESS
> declaration. (it has different LOOKUP_xxx declarations).
>
> Can you help here?

Your only option (which is far the best [performance, functionality] than
anything else) is FUSE from the 2.6.27 kernel.

No need for kernel NTFS support which may or may not cause unexpected
problems for you.

Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T08:12:56Z

On Sun, 31 Aug 2008, Werner Baumann wrote:

> Szabolcs Szakacsits wrote:
> >> What is the "bunch of things" to make 'mount -t ntfs-3g ...' work for an
> >> unprivileged user?
> >
> > http://ntfs-3g.org/support.html#useroption
> >
> It would like not only to know "what to do", but "how it works". The
> mount(8)-program executes this code, immediately after parsing the
> command line:
>
> if (getuid () != geteuid ()) {
> suid = 1;
> if (types || options || readwrite || nomtab || mount_all ||
> fake || mounttype || (argc + specseen) != 1)
> die (EX_USAGE, _("mount: only root can do that"));
> }
>
> - mount(8) usually is setuid root (otherwise unprivileged mounts
> *with* an entry in fstab would not work)
> - when the "-t" option is present on the command line, "types" is
> not NULL
> - both conditions are true and mount will terminate.
>
> *How* do you get around this?

Ok, so there are mounts which don't support it yet. This only makes the
current unprivileged mount situation more unfortunate ...

This is what you wrote previously:

: As the user uses some other program for mounting, he can't expect umount
: to unmount. Please don't mix up the traditional way (mount an fstab) and
: the fuse way.

I don't agree with the first one (user feedbacks but it's also a personal
opinion).

I also don't agree about having two (actually many hundred) different ways
to mount/unmount file systems is a good thing (the explanation is KISS,
Occam's razor, etc). I don't mind alternative ways (I [must] use them all
the time) but users, frameworks, software expect well-known, standard
behaviors and by not conforming to them opens Pandora's box.

> > If you think that an unprivileged ntfs-3g user can overtake the system in
> > whatever way (malware, etc) then we would be very greatful if you could
> > explain technically how it's possible, or if you just simply demonstrate
> > it.
> >
> This is the second step. The first step should be your documentation of
> the security policies you implemented (or intended to implement). This
> documentation is lacking (or at least insufficient). All I could find at
> the above link is:
>
> - the user must have "access right" to the device and the mount point.
> (You probably mean read-, write- and execute-permission.)
> - the administrator *may* restrict unprivileged mounts to members of
> a special group. This is not build in, but the administrator must
> explicitly enforce this.
> Is this all of your security policy? What about file mode? May a
> unprivileged user make files world-executable?
>
> I could spend my time reading the source code or running a lot of tests
> to get an answer to this questions. But I do not think this is the way
> to handle security. This can only be the second step to check whether
> your code holds what you promise.
>
> After all, this is about the integrity of the file system. Changing the
> security policy deserves a proper documentation. FAQ is not appropriate
> for this.

The FAQ entry was only a reply to your question. Access handling and
security is documented at the top of the ntfs-3g manual (man ntfs-3g).

Full ownership and permission support is provided separately which is
documented in the first paragraph of the ntfs-3g home page and accessible
at

http://pagesperso-orange.fr/b.andre/security.html

We had no possibility to fully security audit it yet unlike the base
ntfs-3g version (several external and internal security experts, e.g.
Fedora found two, SUSE one security problem which were fixed of course).

Thanks,
Szaka

--
NTFS-3G: http://ntfs-3g.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

linux kernel 2.6.27-rc5 and fuse gives no LOOKUP_ACCESS

2008-08-31T05:28:35Z

Hello,

I tried to make fuse 2.7.4 in order to add it as a kernel module because
I didn't choose it in the kernel configuration of kernel 2.6.27-rc5 and
I need it to access my external USB harddisk and I didn't want to
recompile the kernel (I use Ubuntu 8.04 and compiled a custom kernel. My
external harddisk has a NTFS file system and I enabled usbstorage and
NTFS support in the custom kernel. dmesg output looks identical with
regard to usb storage to Ubuntus generic kernel and the external
harddisk worked under Ubuntu, accessing the location "external harddisk"
with the custom kernel yields an error "fuse missing").

Make gives an error about a missing LOOKUP_ACCESS declaration. I read in
a previous posting to this mailing list that it is supposed to be in
linux/namei.h.

Linux kernel 2.6.27-rc5 namei.h doesn't have a LOOKUP_ACCESS
declaration. (it has different LOOKUP_xxx declarations).

Can you help here?

Thanks and best regards

Lars
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Re: unmounting with /sbin/umount.fuse?

2008-08-31T01:10:34Z

Szabolcs Szakacsits wrote:
>> What is the "bunch of things" to make 'mount -t ntfs-3g ...' work for an
>> unprivileged user?
>
> http://ntfs-3g.org/support.html#useroption
>
It would like not only to know "what to do", but "how it works". The
mount(8)-program executes this code, immediately after parsing the
command line:

if (getuid () != geteuid ()) {
suid = 1;
if (types || options || readwrite || nomtab || mount_all ||
fake || mounttype || (argc + specseen) != 1)
die (EX_USAGE, _("mount: only root can do that"));
}

- mount(8) usually is setuid root (otherwise unprivileged mounts
*with* an entry in fstab would not work)
- when the "-t" option is present on the command line, "types" is
not NULL
- both conditions are true and mount will terminate.

*How* do you get around this?

> If you think that an unprivileged ntfs-3g user can overtake the system in
> whatever way (malware, etc) then we would be very greatful if you could
> explain technically how it's possible, or if you just simply demonstrate
> it.
>
This is the second step. The first step should be your documentation of
the security policies you implemented (or intended to implement). This
documentation is lacking (or at least insufficient). All I could find at
the above link is:

- the user must have "access right" to the device and the mount point.
(You probably mean read-, write- and execute-permission.)
- the administrator *may* restrict unprivileged mounts to members of
a special group. This is not build in, but the administrator must
explicitly enforce this.
Is this all of your security policy? What about file mode? May a
unprivileged user make files world-executable?

I could spend my time reading the source code or running a lot of tests
to get an answer to this questions. But I do not think this is the way
to handle security. This can only be the second step to check whether
your code holds what you promise.

After all, this is about the integrity of the file system. Changing the
security policy deserves a proper documentation. FAQ is not appropriate
for this.

Cheers
Werner

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel