This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 486070 - cant delete bookmark
cant delete bookmark
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lynx (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 689218
  Show dependency treegraph
 
Reported: 2009-02-17 23:29 EST by jagginess
Modified: 2011-03-20 08:02 EDT (History)
3 users (show)

See Also:
Fixed In Version: 2.8.6-24.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 689218 (view as bug list)
Environment:
Last Closed: 2010-02-01 20:12:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
gdb trace (1.83 KB, text/plain)
2010-01-06 06:41 EST, Kamil Dudka
no flags Details
diff to make bookmark permissions compatible with IsOurFile() (636 bytes, patch)
2010-01-12 20:37 EST, Thomas E. Dickey
kdudka: review+
Details | Diff

  None (edit)
Description jagginess 2009-02-17 23:29:46 EST
Description of problem:
cant delete bookmark

Version-Release number of selected component (if applicable):
(lynx -version)
Lynx Version 2.8.6rel.5 (09 May 2007)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.8g, ncurses 5.6.20080927(wide)
Built on linux-gnu Nov 10 2008 06:54:52

How reproducible:


Steps to Reproduce:
1. 'v' to view bookmark
2. 'r' to delete selected bookmark
3.
  
Actual results:
"
Alert!: Unable to reopen temporary file for deletion of link.
  Arrow keys: Up and Down to move.  Right to follow a link; Left to go back.
 H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=h
"

Expected results:


Additional info:

it seems that development probably ceased into actually fixing this as i googled and notice that this is a persistent problem in previous versions..
Comment 1 lexual 2009-02-24 01:33:39 EST
Reproduced with F10
2.8.6-18.fc10
Comment 2 Thomas E. Dickey 2009-04-11 21:41:58 EDT
I hadn't seen this report before (so the comment about
"development probably ceased" is pure speculation).
Google doesn't show me any related reports, based on the
message.

Lynx keeps track of temporary files by their names.
If something deletes a temporary file, that could
confuse lynx.  I don't see any other obvious way to
produce this error message.  Details on how to
reproduce the problem would be useful.
Comment 3 jagginess 2009-04-12 01:37:14 EDT
^^ Deleting a bookmark.. I already told you how to reproduce the problem.


1. Add a bookmark using 'a'. (add a bookmark say for /etc after navigating to '/')
2. Use 'v' to view bookmarks.
3. Highlight the bookmark, and hit 'r' to delete it.


Right after step 3 you should have that message.
"
Alert!: Unable to reopen temporary file for deletion of link.
  Arrow keys: Up and Down to move.  Right to follow a link; Left to go back.
 H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=h
"

^^ If u can't reproduce this error. Then try adding bookmarks using the file navigator. (meaning try adding bookmarks of '/etc' and '/' paths instead of http://)

btw there's other reports of this error on google. 

I'm using debian's lynx(2.8.7dev.9 apr 2008) and it does not have this problem.

"
Lynx keeps track of temporary files by their names.
If something deletes a temporary file, that could
confuse lynx. "

^^ probably lynx is not making temporary files correctly on my system which would be another type of bug. This fc10 install is brand new..
Comment 4 Thomas E. Dickey 2009-04-12 06:32:52 EDT
Two points:

a) you haven't provided enough information for
me to reproduce the problem.  (If it's fc10-specific,
I won't anyway - don't have that).

b) That's the second comment about reports on
google.  A url (or the search terms) would help.
Comment 5 jagginess 2009-04-12 21:58:21 EDT
"(If it's fc10-specific,
I won't anyway - don't have that).
"

^^ uh.. obviously you're not the one who should address this problem then. The title clearly says "FC10" .. get updated..


"Comment #1 From  lexual (floss@lex.hider.name)  2009-02-24 01:33:39 EDT   (-) [reply] -------

Reproduced with F10
2.8.6-18.fc10  
"


^^ was able to reproduce the error as well.

You should close this thread as nobody seems to care about this package.. and some people just don't know how to address problems. Stick with ur firefox. I'll see who wants to fix this..
Comment 6 Bug Zapper 2009-11-18 06:08:20 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2009-12-18 02:57:06 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 8 Kamil Dudka 2010-01-05 12:11:03 EST
I am able to reproduce it even with lynx-2.8.7-1.fc13. Reopening.
Comment 9 Thomas E. Dickey 2010-01-05 21:03:43 EST
On the other hand, I have not encountered this.
Perhaps you can describe the configuration precisely
enough that I can reproduce it.
Comment 10 Kamil Dudka 2010-01-06 06:41:42 EST
Created attachment 381962 [details]
gdb trace

Note it does not happen when running lynx as root.

I am able to get over the bug using the following patch:

--- a/src/LYUtils.c
+++ b/src/LYUtils.c
@@ -5849,8 +5849,8 @@ static FILE *OpenHiddenFile(const char *name, const char *mode)
     } else
 #endif
     if (*mode == 'a') {
-       if (IsOurFile(name)
-           && chmod(name, HIDE_CHMOD) == 0)
+       if (/*IsOurFile(name)
+           &&*/ chmod(name, HIDE_CHMOD) == 0)
            fp = fopen(name, mode);
        else if (lstat(name, &data) != 0)
            fp = OpenHiddenFile(name, binary ? BIN_W : TXT_W);
Comment 11 Thomas E. Dickey 2010-01-06 19:06:38 EST
The IsOurFile check has been there quite a while,
and removing it doesn't answer the question of what
scenario and configuration we're discussing.
Comment 12 Kamil Dudka 2010-01-06 23:05:33 EST
That's of course not what I wanted to say :-) Do you have any idea how the OpenHiddenFile() function is supposed to work? I hadn't had time to elaborate its semantic. In particular, why does it want to return a NULL pointer in my case? Have you looked at the trace from attachment #381962 [details]?

Any hints are highly welcome as I am completely new to the lynx's code. I can also describe the scenario more accurate once you tell me what properties of my configuration are important to make the OpenHiddenFile() happy. Thanks in advance!
Comment 13 Thomas E. Dickey 2010-01-07 05:03:53 EST
I'm the upstream maintainer (I wrote IsOurFile for instance).

In lynx, temporary files are used to store working
copies of webpages and downloaded files.  (Lynx's
source-caching can move much of the webpages into
memory, but still uses temporary files for compress
webpages).

Temporary files are "hidden" (chmod'd to prevent
reading by other users).  They're also limited to
being in directories where other users cannot for
instance rename the file and substitute their own.

The checks are possibly in some cases over/less
restrictive.  Perhaps you're testing in a directory
which is group-writable, for instance.
Comment 14 Kamil Dudka 2010-01-12 09:39:42 EST
(In reply to comment #13)
> I'm the upstream maintainer (I wrote IsOurFile for instance).

Great!  Welcome at the downstream bugzilla :-)  I am actually a new packager of your lynx.  Feel free to ping me if any RH related lyxn's issues arise.

> Temporary files are "hidden" (chmod'd to prevent
> reading by other users).  They're also limited to
> being in directories where other users cannot for
> instance rename the file and substitute their own.

Among others you are checking the temporary file for S_IWGRP (not writable by group) within IsOurFile().  However your code does not seem to guarantee this permission bit to be set accordingly.

> The checks are possibly in some cases over/less
> restrictive.  Perhaps you're testing in a directory
> which is group-writable, for instance.    

Checks may be ok, but the surrounding code should not also be in conflict with them.

I am able to avoid the the bug with:
$ chmod g-w $HOME/lynx_bookmarks.html

I am able to trigger the bug again with:
$ chmod g+w $HOME/lynx_bookmarks.html

What's the proper way to address it?
Comment 15 Thomas E. Dickey 2010-01-12 17:35:33 EST
Well, for the slice we're looking at, lynx is doing
both an existence-check and permissions-check.

You _could_ reverse the order of the chmod/IsOurFile
calls; however if it happens to be pointing to a
symbolic link, then that could point to "any" of the
user's files (and would be a nuisance if it were the
wrong one).

IsOurFile does assume that group-writable files can
be written to be other users.  I note that on many
systems, there's the use of groups that aren't shared
between users.  It's easy to find the available groups,
but I don't recall any automatic way to ensure that
they aren't shared.  Relaxing that part of the check
would have to be done via a configurable setting, e.g.,
in lynx.cfg

When I wrote that, we had some inconclusive discussion
about the t-bit on directories, which amounted to
not trusting that completely.  (On some older systems, it
is possible to set the t-bit but with a different result
than protecting files).

Looking at the code for IsOurFile now, I can see a couple
of places where I could improve the checking - but those
would make it more restrictive than it is now (a different
topic).
Comment 16 Kamil Dudka 2010-01-12 18:09:40 EST
Well, I am fine with keeping IsOurFile() as is, completely.  It's not going to be called for "$HOME/lynx_bookmarks.html" either.  What I am proposing is to ensure lynx sets the proper permission bits for its temporary files, so that all the checks within IsOurFile() pass afterwards.

What happens now is the temporary files has the same permissions as "$HOME/lynx_bookmarks.html".  If we force the file to have more restrictive permissions than the original file, IsOurFile() will be happy.
Comment 17 Thomas E. Dickey 2010-01-12 20:37:44 EST
Created attachment 383388 [details]
diff to make bookmark permissions compatible with IsOurFile()
Comment 18 Kamil Dudka 2010-01-13 03:34:33 EST
Comment on attachment 383388 [details]
diff to make bookmark permissions compatible with IsOurFile()

Thanks!  The patch looks sane and solves the problem for me.  Are you going to apply the patch upstream?
Comment 19 Kamil Dudka 2010-01-13 03:42:15 EST
Maybe a stupid question ... but where is actually placed the official upstream repository?
Comment 20 Kamil Dudka 2010-01-13 04:03:19 EST
built as lynx-2.8.7-2.fc13
Comment 21 Thomas E. Dickey 2010-01-13 04:26:06 EST
yes, I just committed it (had waited for your response).

Lynx repository is two places: my home machine (where
the $LynxId$ keywords are maintained) and lynx.isc.org
(which uses PRCS, maintains the handful of related
versions).  Neither repository is web-accessible.

I snapshot interim diffs from my home machine in

    ftp://invisible-island.net/temp

(see lynx2.8.8dev.2b.patch.gz)

and lynx is in http://lynx.isc.org/current

At the moment I'm working on dialog, intending to fix
backlog for lynx next.  So this would be in 2.8.8dev.3
(I've been slow since I've had a lot of xterm and vile
work recently).
Comment 22 Fedora Update System 2010-01-13 07:47:13 EST
lynx-2.8.6-24.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/lynx-2.8.6-24.fc12
Comment 23 Kamil Dudka 2010-01-13 08:43:10 EST
(In reply to comment #21)
> I snapshot interim diffs from my home machine in
> 
>     ftp://invisible-island.net/temp
> 
> (see lynx2.8.8dev.2b.patch.gz)

Thanks you for the info!  I'll look there when checking for already fixed bugs, and eventually create patches based on the latest snapshot.  But there are actually no bugs opened agains lynx in the RH bugzilla right now.

We have only two RFEs - support for NSS and support for IPv6.  I haven't had time to look closer at them yet.
Comment 24 Fedora Update System 2010-01-15 17:14:34 EST
lynx-2.8.6-24.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lynx'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0632
Comment 25 Fedora Update System 2010-02-01 20:12:02 EST
lynx-2.8.6-24.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.