GNU bug report logs - #19765
tail -F stops watching when read permissions are removed

Previous Next

To reply to this bug, email your comments to 19765 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: tail -F stops watching when read permissions are removed
Date: Wed, 4 Feb 2015 10:22:11 +0000

When watchnig a file by name with "tail -F", if read permissions
are removed, tail stops watching even though it has a file
descriptor open on the file.

With inotify:

$ : > file
$ tail -F file &
[1] 20796
$ exec 3>> file
$ echo 1 >&3
1
$ chmod 0 file
tail: %                                                                                                                                                        cannot watch ‘file’: Permission denied
tail: ‘file’ has become inaccessible: Permission denied
$ echo 2 >&3  ## not detected at this point
$ chmod +r file
tail: ‘file’ has become accessible
# new content not displayed yet.
$ echo 3 >&3
1   ## all lines displayed
2
3

Without inotify:

$ : > file
$ tail -F ---disable-inotify file &
[1] 20903
$ exec 3>> file
$ echo 1 >&3
1
$ chmod 0 file
$ echo 2 >&3
2  # not detected yet
$ tail: ‘file’ has become inaccessible: Permission denied

$ echo 3 >&3
$ chmod +r file
$ tail: ‘file’ has become accessible
1
2
3

(same except there's a delay before tail detects the file is no longer
readable).

Note that the file in that case is still accessible, one can
still do a stat() on it to check that the file is still the same
one. That's different from when one of the directory components
becomes unreadable/unsearchable, in which case tail can't tell
if it's still reading the right file as in:

   tail -F foo/bar &
   chmod 0 foo

There, tail still has an open file descriptor to foo/bar, but
can't tell if it still points to the "foo/bar" file, so it's
acceptable for it to stop watching in that case.

With inotify though, it doesn't unless the file attributes are
changed (chmod...) or the file is renamed. I think I'll raise a
separate bug report for that and directory components being
renamed.

[tested with git head]

-- 
Stephane

Message #8 received at 19765 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Stephane Chazelas <stephane.chazelas <at> gmail.com>, 
 19765 <at> debbugs.gnu.org
Subject: Re: bug#19765: tail -F stops watching when read permissions are
 removed
Date: Thu, 05 Feb 2015 13:07:46 +0000

On 04/02/15 10:22, Stephane Chazelas wrote:
> When watchnig a file by name with "tail -F", if read permissions
> are removed, tail stops watching even though it has a file
> descriptor open on the file.
> 
> With inotify:
> 
> $ : > file
> $ tail -F file &
> [1] 20796
> $ exec 3>> file
> $ echo 1 >&3
> 1
> $ chmod 0 file
> tail: %                                                                                                                                                        cannot watch ‘file’: Permission denied
> tail: ‘file’ has become inaccessible: Permission denied
> $ echo 2 >&3  ## not detected at this point
> $ chmod +r file
> tail: ‘file’ has become accessible
> # new content not displayed yet.
> $ echo 3 >&3
> 1   ## all lines displayed
> 2
> 3
> 
> Without inotify:
> 
> $ : > file
> $ tail -F ---disable-inotify file &
> [1] 20903
> $ exec 3>> file
> $ echo 1 >&3
> 1
> $ chmod 0 file
> $ echo 2 >&3
> 2  # not detected yet
> $ tail: ‘file’ has become inaccessible: Permission denied
> 
> $ echo 3 >&3
> $ chmod +r file
> $ tail: ‘file’ has become accessible
> 1
> 2
> 3
> 
> (same except there's a delay before tail detects the file is no longer
> readable).
> 
> Note that the file in that case is still accessible, one can
> still do a stat() on it to check that the file is still the same
> one. That's different from when one of the directory components
> becomes unreadable/unsearchable, in which case tail can't tell
> if it's still reading the right file as in:
> 
>    tail -F foo/bar &
>    chmod 0 foo
> 
> There, tail still has an open file descriptor to foo/bar, but
> can't tell if it still points to the "foo/bar" file, so it's
> acceptable for it to stop watching in that case.
> 
> With inotify though, it doesn't unless the file attributes are
> changed (chmod...) or the file is renamed. I think I'll raise a
> separate bug report for that and directory components being
> renamed.
> 
> [tested with git head]
> 

Handling of files that only change perms is awkward.
In the inotify case we don't close the associated watch descriptor
so continue to process events, though ignore them as we've closed the file.

Another problem in this situation with inotify is that write events between
the chmod a-r and a+r are lost, thus not outputting new data until
the next write event.

Another larger problem in this situation with and without inotify
is that the whole file is output, when tail outputs next.
That's documented as a FIXME-maybe in the code.

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.