Subject: A special case of guest access

From: [email-masked]
Date: Tue, 28 Oct 97 10:53:26 +0100

Hi all!

I have a guest account up and running with no problems (thanks all!)
using wu-ftpd beta 15 on redhat linux.

Now on to the next project...

I want a group of users to use the same directory tree all being guest
users and I want every created directory/file to be owned by the creator
as user and a group that all these users belong to having the same
rights as the creating user, i.e rwx rights for the group as well. Why?
Because I want to be able to see who uploaded/created any file/directory
but all users must be able to create/delete/move/etc files and
directories...

How do I do this? I ask you this because I noticed that with my first
guest account the group rights are only r-x and I have not found any way
of setting the rights on the group level so to speak...

I hope you understand my "explanation/question" (I hardly do myself :-)
). I would very much appreciate any help on this matter and (as usual)
it is a bit urgent...

Thanks!

/Per

---

From: Michael Brennen <[email-masked]>
Date: Tue, 28 Oct 1997 08:10:47 -0600 (CST)

Do *not* put an 'upload' directive in /etc/ftpaccess for those
directories.  Create a login account for each user, put them all in the
same group.  Set the CMASK in ~/src/ftpd.c to 002; uploaded files will be
owned buy the individual account, with 664 perms on the files. 

   -- Michael

---

From: Anders Thulin <[email-masked]>
Date: Tue, 28 Oct 1997 15:43:43 +0100 (MET)

Michael Brennen writes:

> same group.  Set the CMASK in ~/src/ftpd.c to 002; [...]

  This is probably OK if *all* FTP-accounts share the same semantics as
regards group rights.  But if the accounts mentioned are special that
way, and there are other accounts with other semantics, some
discrimination functionality must be implemented that sets umask()
according to the type of account.

  There's a similar problem with disk quotas -- if a group of users
(with different FTP accounts, and thus UID's) should share a common
pool of disk space, associated with the group, the FTP server must somehow
switch over to the UID associated with that quota assignment, without
for that reason drop the login name for logging purposes.
(Assuming disk quota is based on UID rather than GID, of course.)

---

From: [email-masked]
Date: Tue, 28 Oct 97 15:52:40 +0100

> (Assuming disk quota is based on UID rather than GID, of course.)

Do you mean that with this setup disk quotas based on group won't work?
If so, is there a solution?

/Per

---

From: Michael Brennen <[email-masked]>
Date: Tue, 28 Oct 1997 09:03:46 -0600 (CST)

> according to the type of account.

Yup; I wasn't addressing the total picture, just what he wanted to do.  In
other cases one might be able to use upload directives in /etc/ftpaccess
to set specific ownership/permissions.  wu-ftpd has its config limits, and
not all requirements may be able to be met at once.  Understanding the
entire picture is necessary in any case.

   -- Michael

---

From: "T's Mailing Lists" <[email-masked]>
Date: Tue, 28 Oct 1997 19:40:51 +0000 (GMT)

Well I have missed this thread a bit, and it might be that I'm a bit off
here, but, gentlemen, isn't this not >exactly< the situation I have
been facing and what is >exactly< resolved by the patch I have posted
here a while ago? Correct me if I'm wrong.

http://www.spin.ch/SPIN/tpo/homepage/linux/academ-patch.html

Cheers,
*
t

> of setting the rights on the group level so to speak...

--------------------------------------------------------------------------------
                   Tomas Pospisek's mailing-lists mailbox   
           www.SPIN.ch - Internet Services in Graubuenden/Switzerland
--------------------------------------------------------------------------------
Tom: So far, der winter kommt, ich schaff mir glaub ich noch ein paar
Tom: Zyxel traffos an...
Roli: Aber genug davon nehmen. Wenn die Dinger kapput gehen werden sie 
Roli: nicht mehr warm.

---

From: "T's Mailing Lists" <[email-masked]>
Date: Tue, 28 Oct 1997 22:57:44 +0000 (GMT)

> here, but, gentlemen, isn't this not >exactly< the situation I have
             ^^^^^^^^^
well this is really stupid, I meant the people discussing that
particualar problem, but of course that's for everybody. Sorry.
*
t

---

From: "James O'Byrne" <[email-masked]>
Date: Tue, 28 Oct 1997 16:26:32 -0500

I noticed when logging in, a user who had no home dir, was given access
to the /.  This was unacceptable, so I made some changes to the source.

Sysadmins now have the choice of detering users sans home dir from
logging in with the -h (I just picked that as it was unused) option in
inetd.conf

the program operates normally without the -h.

I had not seen anything in your faq or patch readme files concerning
this.

James O'Byrne
if anyone wants the source code let me know.

-- 
mailto:[email-masked]

---

From: "T's Mailing Lists" <[email-masked]>
Date: Thu, 30 Oct 1997 16:02:13 +0000 (GMT)

Bizzare - on my machine (Linux) a user without homedir (i.e.
nonsens-homedir like /this/is/no/homedir) doesn't get an access at all...

*
t