Subject: RE: Solaris 2.6 Guest-root restricted-uid setup

From: David Stringer <[email-masked]>
Date: Mon, 3 May 1999 11:10:18 -0600

> -----Original Message-----
> From:	Gregory A Lundberg [SMTP:[email-masked]]
> Sent:	Thursday, April 29, 1999 8:14 AM
> To:	David Stringer
> Cc:	[email-masked]'
> Subject:	Re: Solaris 2.6 Guest-root restricted-uid setup
> 
> On Wed, 28 Apr 1999, David Stringer wrote:
> 
> > I am in the process of upgrading our version of wu-ftpd to the latest
> > and greatest release, and I am having one hell of a time getting the
> > guestgroup/guest-root/restricted-gid commands to work.
> > 
> > What we would like to have is all guest-users locked into their home
> > directories (via restricted-gid), and then have one common root
> > directory for all guest users (via guest-root).
> > 
> > Example: User has the following NIS+ entry
> > std:PASSWD:103:50001::/export/home/std:/usr/local/bin/bash:10689::::::
> > 
> > So when this user logs in we would like to chroot to /export/home, and
> > have this user locked into the directory std. (*I realize this can be
> > done by using guestgroup and the '/./' hack of the passwd entry, but
> > we have way to many entries to be attempting this.*)
> > 
> > As I understand all the documentation, if I specify the following in
> > ftpaccess:
> > guest-root 	/export/home *
> > restricted-gid	ituser
> > 
> > Restricted-gid locks user into account and seems to work fine, but
> > guest-root which should chroot to /export/home, and then look up the
> > user in /export/home/etc/passwd doesn't appear to work at all. (User
> > will end up in home directory but can browse the entire file system.)
> > 
> > (? should guest-root work with NIS+, if /export/home/etc/nsswitch.conf
> > points to nisplus ? )
> 
> I'd be real surprised if it worked with nsswitch.conf.  I certainly never
> coded it to.
> 
	[David Stringer]  
	Ok, thanks.

> > The only way I have been able to accomplish what I want is by setting
> the
> > following in ftpaccess:
> > guest-group 	ituser
> > guest-root 	/export/home
> > restriced-gid ituser
> 
> Yeah, you told it where guests were to be root'd but you didn't tell it
> who were to be guests until you added guest-group.  Personally, I like
>   guestuser *
>   realuser ftp
> since it makes everyone except the anonymous FTP user a guest.
> 
> > Then in the subdirectory of /export/home, I created soft links:
> > ln -s . export
> > ln -s . export/home
> > 
> > Is there a better way to be doing this ? What else am I doing wrong ?
> 
> huh?  so you have a softlink /export/home/export -> /export/home and
> another /export/home/export/home -> /export/home ???
> 
	[David Stringer]  
	All of our NIS entries point to /export/home/Username.
	Guestroot is supposed to be examing /export/home/etc/passwd for
directories. Fine I understand this but this doesn't work well for us
because maintaining two passwd files is impractical for 100,000+ users.
Somewhere guestgroup/guest-root/restriced-id is grabbing the users directory
from NIS plus, and since the NIS entries have export/home I created the soft
links so it would look like this: /export/home/export/home/Username and lock
them in their appropiate directory.

> Dunno what's going on here but I'll guess that the /export/home/etc/passwd
> file has home directory entries starting with '/export/home'
> 
	[David Stringer]  
	Something strange is going on here. I have been unable to get the
/export/home/etc/passwd file to work properly. 

> when using these features of VR17, the chroot-local etc/passwd MUST be
> consistent with the INTERNAL view the user will have.  So, if usera has a
> real home of /export/home/usera (as shown in /etc/passwd) then the local
> etc/passwd should say simply /usera
> 
	[David Stringer]  
	Yes I understand this. So if I read this properly, the workable
options are:
	1. Use the guestgroup/passwd file hack
(/export/home/./export/home/username)
	2. Create another passwd file for all guest users
(/export/home/etc/passwd)

	Thanks,
	David Stringer

> -- 
> 
> Gregory A Lundberg              Senior Partner, VRnet Company
> 1441 Elmdale Drive              [email-masked]
> Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 3 May 1999 13:26:22 -0400 (EDT)

On Mon, 3 May 1999, David Stringer wrote:

> So if I read this properly, the workable options are:
> 	1. Use the guestgroup/passwd file hack (/export/home/./export/home/username)
> 	2. Create another passwd file for all guest users (/export/home/etc/passwd)

First off, I handle the problem by hacking my useradd / userdel scripts to
create / delete the FTP passwd and group file entries when it does the
main system passwd / group files.

I could see an argument for not requiring the FTP-local passwd/group
files.  It would take some syntax in the ftpaccess file to tell the daemon
when it sees guest-root to use the system /etc/passwd file to locate the
user's home directory and strip the guest-root directory from the front of
it.

Without an FTP-local passwd file some things will break:

 - No usernames or group names when doing 'ls'
 - No ~ globbing for CWD, etc.

I'd have to think about other ramifications of not having an FTP-local
passwd or group file.

Since none of the problems (that I've thought of) would prevent normal
operation of the daemon in all other respects, if you ask and are willing
to wait a week or so for me to get 'round to it, I could do up a patch for
you.

--