05-09-2001
got it....
Okay got it working at last, let me tell you what I have had to do, so, as you say we can all benefit...
Firstly I modified /etc/passwd and /etc/group to read:
user:x:500:500::/home/./user/:/etc/ftponly
root::0:root
user::500:user
You have to ensure that /etc/ftponly is in the list contained in the file /etc/shells. Then I created etc, bin and lib directories under /home - the location of these are vital, as I will show soon. In /home/etc I created a passwd file with the entry in /etc/passwd above as well as one for root thus:
root:x:0:0::/etc/ftponly
I also created a group file in /home/etc with the entries in /etc/group listed above. You only want these entries in these files, not the complete corresponding files as chrooted users will be able to see these.
Then I copied /bin/ls into /home/ls. Then I added two entries into /etc/ftpaccess:
class all guest *
guestgroup user
Class creates a class for the guest ftp, * means that connections from anywhere are allows as this class. Guestgroup indicates that the ftp login for users in group user will be guest ftp logins, which is needed for chrooting the account. Simple so far.
This is the bit that got me - I managed to log into the jail, and stay stuck in there, but could not see anything. I figured it was ls not working properly, so this is where the /home/lib directory comes into play. In here you need to replicate the state of the libraries and links in /lib that are used by ls.
So I used ldd /bin/ls to check things out. You need the following in /home/lib:
ld-2.1.94.so
libc-2.1.94.so
libtermcap.so.2.0.8
Then create soft links to these from the following, in respective order:
ld-linux.so.2
libc.so.6
libtermcap.so.2
What I discovered, after pulling my hair out many times, is exactly what mib said, this directory and bin needs to be in the directory you set to chroot to, NOT in the directory you set to subsequently chdir to. This is the mistake I made, so if it /etc/passwd the entry was:
user:x:500:500::/home/./user/:/etc/ftponly
~etc, ~bin and ~lib should be under /home not /home/user. Once this is all in place you have a fully functional chrooted guest ftp account.
One thing to bear in mind is this: this is obviously not a complete jail, as the chroot is done on /home so, that is effectively / which means the user can still get out into /home and possibly move into other people's directories. You can operate the chroot on /home/user but this would mean the ~etc, ~bin and ~lib directories in EACH users chroot environment - this is 5 megs in total (99% people the libraries) if you have say 100 customers on a machine, that 500 megs of disk space in just setting up the restricted ftp access, thats a lot of space, relatively speaking. So you can just chroot on /home and then you only need one set of those directories, and take chmod out of the priviledges for guest ftp accounts in /etc/ftpaccess. That should stop anyone chmoding someone elses files then deleting them. Obviously this need more consideration and is site dependent.
Hoped this helped someone!
Regards
10 More Discussions You Might Find Interesting
1. UNIX for Dummies Questions & Answers
I need to create a user that only has access to 1 directory (e.g. /vol/mita/test). The user needs to be able to rsh into that directory to run a script. The user should not be able to navigate to any other directories above /vol/mita/test. Any help would be appreciated! (4 Replies)
Discussion started by: ngagne
4 Replies
2. UNIX for Dummies Questions & Answers
I have a need to allow only certain IP addresses to access a machine running solaris 9. I am not sure how this can be accomplished.
Thanks in advance for your help.
Patch (2 Replies)
Discussion started by: patch
2 Replies
3. Solaris
Hi All,
I'm on Solaris 8, I need to provide Read-only access to a user to 2 directories only.
Using rsh (restricted shell) as the user's login shell, I can restrict the user's access to a certain directory only, but how can I set in such a way that the user can access only the 2 directories... (4 Replies)
Discussion started by: max_min
4 Replies
4. UNIX for Advanced & Expert Users
I'm the admin in a shop in which my developers have and use the root account, all UNIX newbies.
I've been unable to convince management myself that this is an unacceptable practice.
I've looked in a couple books I have and can't find any chapters, discussions, etc that make the argument that... (2 Replies)
Discussion started by: keith.m
2 Replies
5. Solaris
We want to secure access to a server by restricting the number of users who can login to it. Our users are NIS users. Only few of them can telnet/ssh this server.
Do you have any idea on how to implement that?
thanks. (1 Reply)
Discussion started by: melanie_pfefer
1 Replies
6. UNIX for Advanced & Expert Users
Hi All,
I am facing a problem, regarding code security on a server.
We have configured a server which contains our code (ear present in jboss/server/xyz/deploy) in it, and need to bind the code to the server itself so that no one can take the code out of the. the problem is that the password of... (3 Replies)
Discussion started by: akshay61286
3 Replies
7. Solaris
Dear All,
I have created a user called "x" who is allowed only to FTP and it is working fine. Here my problem is, I want to give access to a particular directory say for eg:- /dump/test directory. I don't find any option in the useradd command to restrict access to this particular directory only... (1 Reply)
Discussion started by: Vijayakumarpc
1 Replies
8. Solaris
Hi all.
I've had a quick look around but cant see anything exactly matching my requirements.
I have a new T2000 running S10. Im looking to restrict the no. cores that a S10 non-global zone can use to 1 only. The box is single CPU but 8core.
I want to do this to save on some software... (4 Replies)
Discussion started by: boneyard
4 Replies
9. UNIX for Dummies Questions & Answers
Hello,
I am using MySecureShell to chroot all sftp accesses. The problem that I have is that my boss does not want root to be able to use sftp. Root should still be able to ssh. Any ideas? (2 Replies)
Discussion started by: mojoman
2 Replies
10. Solaris
Dear all,
I am administering a DC environment of over 100+ Solaris servers used by various teams including Databases.
Every user created on the node belonging to databases is assigned group staff(10) .
I want that all users belonging to staff should NOT be able to execute certain system... (6 Replies)
Discussion started by: Junaid Subhani
6 Replies
LEARN ABOUT FREEBSD
rmuser
RMUSER(8) BSD System Manager's Manual RMUSER(8)
NAME
rmuser -- remove users from the system
SYNOPSIS
rmuser [-yv] [-f file] [username ...]
DESCRIPTION
The rmuser utility removes one or more users submitted on the command line or from a file. In removing a user from the system, this utility:
1. Removes the user's crontab(1) entry (if any).
2. Removes any at(1) jobs belonging to the user.
3. Sends a SIGKILL signal to all processes owned by the user.
4. Removes the user from the system's local password file.
5. Removes the user's home directory (if it is owned by the user), including handling of symbolic links in the path to the actual home
directory.
6. Removes the incoming mail and POP daemon mail files belonging to the user from /var/mail.
7. Removes all files owned by the user from /tmp, /var/tmp, and /var/tmp/vi.recover.
8. Removes the username from all groups to which it belongs in /etc/group. (If a group becomes empty and the group name is the same as the
username, the group is removed; this complements adduser(8)'s per-user unique groups.)
9. Removes all message queues, shared memory segments and semaphores owned by the user.
The rmuser utility refuses to remove users whose UID is 0 (typically root), since certain actions (namely, killing all the user's processes,
and perhaps removing the user's home directory) would cause damage to a running system. If it is necessary to remove a user whose UID is 0,
see vipw(8) for information on directly editing the password file.
If rmuser was not invoked with the -y option, it will show the selected user's password file entry and ask for confirmation that the user be
removed. It will then ask for confirmation to delete the user's home directory. If the answer is in the affirmative, the home directory and
any files and subdirectories under it will be deleted only if they are owned by the user. See pw(8) for more details.
As rmuser operates, it informs the user regarding the current activity. If any errors occur, they are posted to standard error and, if it is
possible for rmuser to continue, it will.
The options are as follows:
-f file The rmuser utility will get a list of users to be removed from file, which will contain one user per line. Anything following a
hash mark ('#'), including the hash mark itself, is considered a comment and will not be processed. If the file is owned by anyone
other than a user with UID 0, or is writable by anyone other than the owner, rmuser will refuse to continue.
-y Implicitly answer ``yes'' to any and all prompts. Currently, this includes prompts on whether to remove the specified user and
whether to remove the home directory. This option requires that either the -f option be used, or one or more user names be given
as command line arguments.
-v Enable verbose mode. Normally, the output includes one line per removed user; however, with this option rmuser will be much more
chatty about the steps taken.
username Identifies one or more users to be removed; if not present, rmuser interactively asks for one or more users to be removed.
FILES
/etc/master.passwd
/etc/passwd
/etc/group
/etc/spwd.db
/etc/pwd.db
SEE ALSO
at(1), chpass(1), crontab(1), finger(1), passwd(1), group(5), passwd(5), adduser(8), pw(8), pwd_mkdb(8), vipw(8)
HISTORY
The rmuser utility appeared in FreeBSD 2.2.
BUGS
The rmuser utility does not comprehensively search the file system for all files owned by the removed user and remove them; to do so on a
system of any size is prohibitively slow and I/O intensive. It is also unable to remove symbolic links that were created by the user in /tmp
or /var/tmp, as symbolic links on 4.4BSD file systems do not contain information as to who created them. Also, there may be other files cre-
ated in /var/mail other than /var/mail/username and /var/mail/.pop.username that are not owned by the removed user but should be removed.
The rmuser utility has no knowledge of YP/NIS, and it operates only on the local password file.
BSD
May 10, 2002 BSD