Empty context when unlink of hidden files

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Empty context when unlink of hidden files

Leandro Franco
Hi,

I'm having a problem and the answer seems to be in the "UID, GID, and
release" discussion (
http://sourceforge.net/mailarchive/message.php?msg_id=9847642)...

It seems that release doesnt have a context associated and trying to
get a uid there would return 0, I understand why but this meddles with
a particular case....

My FS bases the security on the pid's, when we try to delete an open
file fuse will rename it to a hidden_something and the file system
will allow it but when the file is release it calls the unlink
function with a pid=0 and the FS wont allow it.... and i will end up
with a lot of hidden files....

Is there an ok way to solve it? like passing the context of the
original unlink call to release?... or should i go for the ugly option
of allowing unlinking if the name is similar to fuse_hidden ?.....

any ideas?...


Another unrelated request for Miklos: Could it be possible to have the
groups of a process in the context? it would be handy for me since I
have to look for it in /proc/*/status with a pid... another useful
addition for the future would be the environ of the process to pass
information in environment variables (but it will be a while before
working on that.... so i better dont push it :) )


Thanks for everything and congrats for getting into the kernel... it
will make life easier for all of us


Leandro Franco


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Empty context when unlink of hidden files

Miklos Szeredi
> I'm having a problem and the answer seems to be in the "UID, GID, and
> release" discussion (
> http://sourceforge.net/mailarchive/message.php?msg_id=9847642)...
>
> It seems that release doesnt have a context associated and trying to
> get a uid there would return 0, I understand why but this meddles with
> a particular case....
>
> My FS bases the security on the pid's, when we try to delete an open
> file fuse will rename it to a hidden_something and the file system
> will allow it but when the file is release it calls the unlink
> function with a pid=0 and the FS wont allow it.... and i will end up
> with a lot of hidden files....
>
> Is there an ok way to solve it? like passing the context of the
> original unlink call to release?... or should i go for the ugly option
> of allowing unlinking if the name is similar to fuse_hidden ?.....
>
> any ideas?...

Maybe allowing unlink if pid == 0?

You will never get zero pid otherwise.  It's not the nicest solution,
but it sort of makes sense, since the "virtual delete" was already
authorized when the filesystem's rename() was called.  So allowing the
unlink when called from release() should not cause problems, should it?
>
> Another unrelated request for Miklos: Could it be possible to have the
> groups of a process in the context?

That's something that would make sense.


> it would be handy for me since I have to look for it in
> /proc/*/status with a pid...

Can you post this code?  It could be included in libfuse.  I think
this is probably the best way to get the group list, since sending it
with each request is a waste of bandwidth for the vast majority of
filesystems.  And the group list can have arbitrary length, though
it's pretty short usually.

> another useful addition for the future would be the environ of the
> process to pass information in environment variables (but it will be
> a while before working on that.... so i better dont push it :) )

The policy is for the kernel (and so filesystems) to ignore the
environment variables of a process.  Environment variables are a
userspace thing and the kernel has no business with them.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Empty context when unlink of hidden files

Leandro Franco
hi

>
> Maybe allowing unlink if pid == 0?
>
> You will never get zero pid otherwise.  It's not the nicest solution,
> but it sort of makes sense, since the "virtual delete" was already
> authorized when the filesystem's rename() was called.  So allowing the
> unlink when called from release() should not cause problems, should it?

yea, that might be the simplest solution...


> >
> > Another unrelated request for Miklos: Could it be possible to have the
> > groups of a process in the context?
>
> That's something that would make sense.
>
>
> > it would be handy for me since I have to look for it in
> > /proc/*/status with a pid...
>
> Can you post this code?  It could be included in libfuse.  I think
> this is probably the best way to get the group list, since sending it
> with each request is a waste of bandwidth for the vast majority of
> filesystems.  And the group list can have arbitrary length, though
> it's pretty short usually.

ok, i will take a look of the fuse code to see where i can put it


>
> > another useful addition for the future would be the environ of the
> > process to pass information in environment variables (but it will be
> > a while before working on that.... so i better dont push it :) )
>
> The policy is for the kernel (and so filesystems) to ignore the
> environment variables of a process.  Environment variables are a
> userspace thing and the kernel has no business with them.
>

too bad... parsing the /proc/*/environ file looks kind of messy


thanks

Leandro Franco


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Empty context when unlink of hidden files

Miklos Szeredi
> > > it would be handy for me since I have to look for it in
> > > /proc/*/status with a pid...
> >
> > Can you post this code?  It could be included in libfuse.  I think
> > this is probably the best way to get the group list, since sending it
> > with each request is a waste of bandwidth for the vast majority of
> > filesystems.  And the group list can have arbitrary length, though
> > it's pretty short usually.
>
> ok, i will take a look of the fuse code to see where i can put it

BTW, I see one problem: the 'pid' field in fuse_context is not the
process id, but in fact the thread id, that is in /proc/*/task.

For single threaded apps the thread ID and process ID are equal, so
there's no problem.  But for multithreaded apps I don't know any way
to find the process ID from the thread ID, and so to find a thread,
all processes have to be searched in proc, which could be a rather
slow process.  Maybe caching this info is the solution, but it's not
all that elegant.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel