| Summary: | .listing has sprung into existence. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alexander Todorov <atodorov> |
| Component: | wget | Assignee: | Karsten Hopp <karsten> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | CC: | pknirsch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-18 13:23:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Alexander Todorov
2011-11-15 15:10:24 UTC
Maybe i'm misunderstanding the manpage, but --no-remove-listing pretty clearly states that the .listing files won't be overwritten if you use that option:
--no-remove-listing
Don’t remove the temporary .listing files generated by FTP retrievals. Normally, these files contain the raw directory listings received from FTP servers. Not removing them can be useful for
debugging purposes, or when you want to be able to easily check on the contents of remote server directories (e.g. to verify that a mirror you’re running is complete).
Note that even though Wget writes to a known filename for this file, this is not a security hole in the scenario of a user making .listing a symbolic link to /etc/passwd or something and asking
"root" to run Wget in his or her directory. Depending on the options used, either Wget will refuse to write to .listing, making the globbing/recursion/time-stamping operation fail, or the symbolic
link will be deleted and replaced with the actual .listing file, or the listing will be written to a .listing.number file.
Even though this situation isn’t a problem, though, "root" should never run Wget in a non-trusted user’s directory. A user could do something as simple as linking index.html to /etc/passwd and
asking "root" to run Wget with -N or -r so the file will be overwritten.
So i would say this is working as documented and intended.
Thanks & regards, Phil
(In reply to comment #1) > Note that even though Wget writes to a known filename for this file, > this is not a security hole in the scenario of a user making .listing a > symbolic link to /etc/passwd or something and asking > "root" to run Wget in his or her directory. Depending on the > options used, either Wget will refuse to write to .listing, making the > globbing/recursion/time-stamping operation fail, or the symbolic > link will be deleted and replaced with the actual .listing file, or > the listing will be written to a .listing.number file. > Maybe I'm misunderstanding the man page too. It says that either: 1) write to the .listing file fails 2) .listing is removed and replaced with new content 3) the listing is written to .listing.number file In my case 1) happens and exit code is 0. I agree with Phil here, this is working as intended. You need to add the -N parameter if you'd like to overwrite .listing with the lasted one. |