headers
fred wu | 3 Aug 2004 11:09
Picon
Favicon

File access with download?

Dear All,

  I have brother with the following problem for a long
time.Could anyone give me a hand? :(

  If I download a file from internet to /home, only
the /tmp will have file access and "rename" function
will be taken place in /home, right?

  Are there any ways to get the file path in /home?
(ie. I don't need to have /tmp/oAbdEYCJK but I need
/home/download.zip)

 
  Thank you for all your time! This question really
brother me a lot!

  Thanks!

Best,
Fred

_________________________________________________________
必殺技、飲歌、小星星...
浪漫鈴聲  情心連繫
http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/
Permalink | Reply | 2 comments |
headers
Ernest N. Wilcox Jr. | 3 Aug 2004 18:44
Favicon

Re: Dazuko-devel Digest, Vol 17, Issue 1

On Wednesday 31 December 1969 06:59 pm, dazuko-devel-request <at> nongnu.org wrote:
  | cut ----------------------------------------------------------------------
  |
  | Message: 1
  | Date: Tue, 3 Aug 2004 17:09:06 +0800 (CST)
  | From: =?big5?q?fred=20wu?= <thizaccess <at> yahoo.com.hk>
  | Subject: [Dazuko-devel] File access with download?
  | To: dazuko-devel <at> nongnu.org
  | Message-ID: <20040803090906.27968.qmail <at> web53810.mail.yahoo.com>
  | Content-Type: text/plain; charset=big5
  |
  | Dear All,
  |
  |   I have brother with the following problem for a long
  | time.Could anyone give me a hand? :(
  |
  |   If I download a file from internet to /home, only
  | the /tmp will have file access and "rename" function
  | will be taken place in /home, right?
  |
  |   Are there any ways to get the file path in /home?
  | (ie. I don't need to have /tmp/oAbdEYCJK but I need
  | /home/download.zip)
  |
  |
  |   Thank you for all your time! This question really
  | brother me a lot!
  |
  |   Thanks!
  |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfram Schlich | 3 Aug 2004 19:28
X-Face

Re: File access with download?

* fred wu <thizaccess <at> yahoo.com.hk> [2004-08-03 11:10]:
> Dear All,
> 
>   I have brother with the following problem for a long
> time.Could anyone give me a hand? :(
> 
>   If I download a file from internet to /home, only
> the /tmp will have file access and "rename" function
> will be taken place in /home, right?
> 
>   Are there any ways to get the file path in /home?
> (ie. I don't need to have /tmp/oAbdEYCJK but I need
> /home/download.zip)

I guess you're talking about temporary files created by your
favorite web browser used for storage of the files you download until
they're downloaded completely. Afterwards, they're moved to the
location and filename you selected when starting the download, right?
Well, you could either add /tmp to the Dazuko scan path list, or you
could configure your favorite web browser to store temporary files
in a subdirectory somewhere beneath your home directory (I don't know
whether that's possible with your favorite browser, though).
--

-- 
Wolfram Schlich; Friedhofstr. 8, D-88069 Tettnang; +49-(0)178-SCHLICH
Permalink | Reply | 0 comments |
headers
John Ogness | 3 Aug 2004 13:09
Picon

Re: File access with download?

fred wu wrote:
>   If I download a file from internet to /home, only
> the /tmp will have file access and "rename" function
> will be taken place in /home, right?
> 
>   Are there any ways to get the file path in /home?
> (ie. I don't need to have /tmp/oAbdEYCJK but I need
> /home/download.zip)

Hi,

For this to work, Dazuko would need to hook the rename() system call. This
would also require the dazuko_access structure to support 2 filenames (one
for the source and one for the destination).

This is a technically difficult task because Dazuko would receive the event
BEFORE the destination file exists. This is a problem for Dazuko since it
relies on inodes (of exising files) to resolve the true path name.

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
John Ogness | 18 Aug 2004 23:05
Picon

2.0.3-pre4 posted

Hi,

I have posted 2.0.3-pre4. I expect this to be the final pre-release 
before 2.0.3. Some minor optimizations and bugfixes have been made to 
address a few reported problems.

There is one major change in this new version. Dazuko will no longer 
require "root" access. This means that anyone who is allowed read/write 
access to /dev/dazuko will also be able to perform file access control. 
Since the Dazuko HOWTO has said from the beginning that /dev/dazuko 
should be owned by root with permissions 600, I think this will cause no 
problems. However, it introduces the ability for a user to have non-root 
processes perform file access control or file access logging (for 
example, processes belonging to a dazuko group). Until now Dazuko 
required the Real UID to be 0 (rather than the Effective UID). This 
means that setuid processes will now also be able to access Dazuko. I am 
anxious to hear feedback on this change, but I feel that it is a 
positive change.

I worked all of last weekend on using the FiST framework to develop 
DazukoFS. I was successful. I have been able to develop a stackable 
filesystem (called DazukoFS) that is based on Dazuko. How does this 
work? DazukoFS is a transparent filesystem that is mounted on top of 
existing file systems. The file systems can be accessed just as before 
with the only difference being that Dazuko can control or log the file 
access events.

Advantages
- kernelspace NFS servers are supported
- based on FiST (building on the experience of another project)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Bihan-Faou | 27 Aug 2004 15:39

resolving full path when creating a new file on freebsd 4.x (and more)

Hi,

Testing dazuko 2.0.3-pre4 on freebsd I noticed that I was never getting the
OPEN/CLOSE events for files that were non-existant previously. After some
investigation, I found that when the file does not exist, the namei() call
in freebsd_get_full_fileinfo() (called from xp_file_struct_check()) returns
ENOENT leading in the name not being resolved.

Here is a patch for freebsd_get_full_fileinfo() that tries to resolve the
first parent directory of a file if the file itself does not exist (ENOENT).

The provided patch has been slightly tested on a FreeBSD 4.9 system with
good success so far.

Also, while there, I have replaced the vrele calls that were following
NDINIT/namei calls with more adequate NDFREE() calls that also free the
memory that could have been allocated during the namei() call.

Now I have another question regarding the closed/modified event:

To support the closed-modified event, dazuko monitors the write system call.
However in FreeBSD there are at least 4 calls that can modify a file:

- write() (already handled)

- writev() (handles scattered buffers for a single write operation)

- pwrite() (write at a specific offset)

- aio_write (asynchronous IO call)
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Ogness | 27 Aug 2004 16:29
Picon

Re: resolving full path when creating a new file on freebsd 4.x (and more)

Patrick Bihan-Faou wrote:
> Testing dazuko 2.0.3-pre4 on freebsd I noticed that I was never getting the
> OPEN/CLOSE events for files that were non-existant previously. After some
> investigation, I found that when the file does not exist, the namei() call
> in freebsd_get_full_fileinfo() (called from xp_file_struct_check()) returns
> ENOENT leading in the name not being resolved.

Yes, as you noticed, name lookups can only be successful for existing files. 
We worked around this issue by making newly created files generate post_open 
events (ie. an ON_OPEN event is generated after the open was completed).

> Here is a patch for freebsd_get_full_fileinfo() that tries to resolve the
> first parent directory of a file if the file itself does not exist (ENOENT).

Thanks. I will check it out this weekend.

> To support the closed-modified event, dazuko monitors the write system call.
> However in FreeBSD there are at least 4 calls that can modify a file:
> 
> [snip]
> 
> Only the first syscall is handled and none of the last 3. Wouldn't that
> invalidate the usefulleness of the closed-modified event ?

Yes you are correct. I am unhappy with this implementation of noticing 
changed files (because of the overhead). I am also unhappy that ON_CLOSE 
events are based on matching file descriptors. Both of these should be 
seriously considered, but it is very limiting at the system call level. This 
will be more easily and efficiently handled once DazukoFS is released.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Patrick Bihan-Faou | 27 Aug 2004 17:08

RE: resolving full path when creating a new file onfreebsd 4.x (and more)

Hi,

> Patrick Bihan-Faou wrote:
> > Testing dazuko 2.0.3-pre4 on freebsd I noticed that I was never
> getting the
> > OPEN/CLOSE events for files that were non-existant previously.
> After some
> > investigation, I found that when the file does not exist, the
> namei() call
> > in freebsd_get_full_fileinfo() (called from
> xp_file_struct_check()) returns
> > ENOENT leading in the name not being resolved.
>
> Yes, as you noticed, name lookups can only be successful for
> existing files.
> We worked around this issue by making newly created files
> generate post_open
> events (ie. an ON_OPEN event is generated after the open was completed).

Well would'nt generating the ON_OPEN event after the open has completed have
a nasty side effect ? Namely the file would already be created even if the
dazuko daemon decided that the open should be blocked.

> > To support the closed-modified event, dazuko monitors the write
> system call.
> > However in FreeBSD there are at least 4 calls that can modify a file:
> >
> > [snip]
> >
> > Only the first syscall is handled and none of the last 3. Wouldn't that
(Continue reading)

Permalink | Reply | 4 comments |

Gmane