Bug 23745 – denying delete and overwrite on guest users has no usefull use IMHO

Bug 23745 - denying delete and overwrite on guest users has no usefull use IMHO

Summary:	denying delete and overwrite on guest users has no usefull use IMHO

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	wu-ftpd (Show other bugs)
Sub Component:
Version:	7.1
Hardware:	All Linux

Priority	low Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Bernhard Rosenkraenzer
QA Contact:	David Lawrence
Docs Contact:

URL:
Whiteboard:
Keywords:	FutureFeature

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2001-01-10 17:26 EST by Arenas Belon, Carlo Marcelo
Modified:	2007-03-26 23:39 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Enhancement
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2001-01-10 17:26:46 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Arenas Belon, Carlo Marcelo 2001-01-10 17:26:14 EST

after setting /etc/ftpaccess for guest use i found that the defaults are
really disturbing, because there is no way to delete or overwrite any file
even if owned for the guest users id as explained on :

  delete     no guest,anonymous
  overwrite no guest,anonymous

i think that setting a chroot home for a user explicitally changing its
home with something like /home/foo/./ should make it to delete and
overwrite files on its own directory (great for virtualhosts)

it should be just :
 
   delete     no anonymous
   overwrite no anonymous

IMHO and seems secure enough

Comment 1 Bernhard Rosenkraenzer 2001-01-12 08:05:10 EST

The use of this is for situations like ibiblio.org was a couple of years ago,
where you could log in as anonymous for download, or as "upload" (=guest user)
for getting write access to /pub/Incoming, where all files are automatically
chowned to ftp:ftp.

I agree that the other use is *far* more common and useful though, changed.

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