Sorry for the last posting, very few have metamail capabilities,
so I resend it in, hopefully, proper format.
I got over 30 answers, and most of them said the same.
Now I know how to do it, but my original intention wa not
met, as it turns out that several programs rely on being
able to rsh to this userid, and modifying these programs
are out of the question.
Anyway, here is the answers I got, starting with my initial
question:
Hello,
I have a (probably) silly question, that I should be able to answer myself,
but I can't...
I want to have a userid that is allowed to NFS mount unix filesystems from
his PC, do FTP file transferes but NOT allowed to login to the unix box.
What is the recommended way of doing this? Is it possible?
-----------------------------------------------------------------------
to handle the ftp part, you'll need an account with a password,
which eliminates the
-user:::::
approach.
why not make the user's shell /bin/true, so they can login
and then get logged out immediately?
One possible solution would be to use "sudo". This is public software and can be
ftp'd from several places on the net. With sudo, you will be able to allow certain
users to execute just certain commands; it can be tailored as you need it.
Give the user either no shell or directly into ftp ie:
PASSWD entry:
rickn:SDFJLKSJDKLFJL:100:10:Rick Niziak:/home/rickn:/bin/ftp or,
rickn:SDFJLKSJDKLFJL:100:10:Rick Niziak:/home/rickn:
Give this user a shell which will exit immediately, and place this shell
in the the file /etc/shells (you'll also have to add the regular shells
here if you do this - /bin/sh /usr/bin/csh etc.)
e.g.
% grep ^dopey /etc/passwd
dopey:zzzzzzzzzzzzz:300:300:Dopey User:/home/dopey:/usr/local/bin/nope
% ls -l /usr/local/bin/nope
lrwxrwxrwx 1 root 10 Aug 31 1993 /usr/local/bin/nope -> /bin/false
% cat /etc/shells
/bin/csh
/bin/sh
/usr/bin/sh
/usr/bin/csh
/usr/local/bin/nope
I think if you make a shell (which consists of a C program that conists
of printf('Go away!\n');
...and call it /bin/noshell
Add /bin/noshell to /etc/shells (to allow ftp access)
Make /bin/noshell the persons shell (so they have a UID but can't log in)
VOILA
Alternatively just making the password field "*" in your password file
and having the csh be his shell wouldn't accomplish the same thing because
they could ftp over a .rhosts file allowing them to login WITHOUT
NEEDING a password. If you also made ~user/.rhosts a root-owned, 0 byte
file without write permissions; you;d probably be pretty safe.
I'd create a program which simply prints out a message like
I'm sorry, but you are not allowed to login to this machine
Make this program the person's shell in /etc/passwd, and add it to
/etc/shells. If you don't add it to /etc/shells, the person will not
be able to FTP.
Of course, some person may decide to change to this interesting new
alternative shell, and then they'll have to get you (or some other
root user) to switch them back. Make sure that you give is a suitably
informative (and scary) name.
1) NFS is not based on useid, if it is exported, everyone has access,
unless you specifically limit by userid, or system.
2) Where are the file's you'd like the user to ftp to? You may want
to read up on how to setup an anonymous ftp. I've used *most*
of it's setup to do similar things. If the files can't be
hidden from the system or logged in users, you could write a
script as the login executable, or not give them one.
You would have to insure that the path could not be updated,
and there were NO shell escapes. There is wu-ftp available,
you could use that?
It is entirely possible. Look at the man page for passwd (5).
In the login-shell field of your user's passwd entry, just put
a non-executable "shell". Then he can FTP but not log in.
Also, NFS mounting is a function of the export of the directory to be mounted.
Check the man pages on export and exportfs.
Set his default shell in the password file to be /bin/true or some other
harmless but useless program (binary program, not shell script).
This will allow him to log in but drop him wihtout allowing him to start a shell.
That way he's still a valid user, just can't run any programs (he has no shell).
We use this method for locking out accounts, runs a program called lockout that
tells users to pay us a visit for a chat :)
Don't give the user a login shell in /etc/passwd or give him a dummy shell
like /bin/dummy. If he tries to login he won't have a shell. The other
option is to make is defautl shell a script file which logs him off.
I am not sure that you can do it in this way. A user has to have a user
account to be able to NFS mount. The workaround may be to give him/her
an account and set up the login script to logout him/her immediately
after logging in. I am not sure what to do about ftp though, you may
have to do some experimenting there.
For the FTP trick, try giving the user a bogus shell entry in
/etc/passwd - he could log in, but would get bounced right out, while
still being able to do FTP.
As for the NFS, he doesn't need a loginid to be able to mount filesystems,
he just needs permission to call the mount command on his own machine,
and an 'access=' entry in the exports file.
Try seting up the /etc/passwd entry as you would for a regular user, and
set his shell to something that won't let him do anything, like /bin/true,
or a little script that says he doesn't have login privs and logs him right
out.
Rune,
I would suggest making his login shell "/bin/false" to prevent him
from logging in and then make sure "/bin/false" is in the file "/etc/shells"
to allow him use of ftp(1).
I haven't tried this on a Sun (works with Linux, though), but I'm
pretty sure it will work. There may also be some underlying security
issues involved with putting "/bin/false" in the "/etc/shells" file.
But, that's a something you'll have to decide for yourself. If anything,
you could do a "ln [-s] /bin/false /bin/nologin" then use "/bin/nologin"
instead of "/bin/false" above. (This leaves "/bin/false" to be used
in a more conventional manner.)
Dear Rune,
I have got arround the ftp-but-no-telnet by putting the following
into the user's .cshrc:
echo ''
echo 'This is an ftp-only account. You are being logged out'
echo ''
logout
You need though to make the user's home directory unwritable
otherwise an alternative .cshrc could be added via ftp. Subdirectories,
for the user to work in, could be writable.
Set up the passwd entry as normal but make the login shell other than a real
shell - we have it issue a suitable warning message and exit.
Rune -
I've wondered the same thing and, in the past, have resolved it like
this:
Compile a C program that simply states (via puts() or whatever)
that you've just attempted to use a non-functioning login. You
can even have this program update a log when users attempt to
use this login if you wish. Now... Use this program as the
"login shell", instead of /bin/sh, csh, whatever, entry in
/etc/passwd. Make sure every loginID using this has its own
unique numerical userid.
This will allow PCs to mount network drives, printers, etc. while
addressing their having a readable login and password in their
autoexec.bat files. At the same time it keeps those same login/password
combinations from being used to actually log into the servers.
Variations of the above can be used to supply other general information
from the server(s) as well, such as: meeting info, etc. I've created
this type of restricted login for things like: System availability,
meetings, user news, etc.
I do similiar things on my machine. I just assign them a ip
address (we use wollongong pathway PC software), put this
ip address in the local host file and hosts.equiv on
the unix machine and they have access.
Not sure if this works for the NFS mount or not. You might need
to go ahead and create a dummy login account and place an
asterisk in the password field so they cannot log in.
Sure, just set his shell to something like "/bin/nologin", which
does something like "echo not allowed", and add it to /etc/shells.
Try giving the user a shell of /bin/true, may need to
list in /etc/shells for ftp.
One way might be to change his login shell to a command like /bin/false
Put '/bin/false' in the Shell field of his /etc/passwd entry.
Yes, make his login shell (last field in his /etc/passwd file entry)
point to some noninteractive command, like /bin/date. This is how my
previous employer allowed NFS mounting and ftp from the user's client
Sun workstations, but not casual user login.
This still leaves a hole ala "rsh server /bin/sh -i" but this can be
denied by working with /etc/hosts.equiv or .rhosts.
To successfully mount the NFS filesystem the user will need a password on
NFS server so he can complete the authentication process with rpc.pcnfsd.
You can prevent logins with the shell field in the passwd file.
Allow FTP access with anonymous FTP or even to the users home directory.
Create a passwd entry for the user with /bin/false as the shell.
Add /bin/false to the /etc/shells file.
joeblow:afSQmaxyj:5000:200:Mr PC User:/ftp/pub:/bin/false
It occurs to me that you could also give them a .login (owned by root) with
/bin/login as the first line (if you don't like the /bin/false shell idea),
although I've never tried that approach. There might be a hole I haven't
thought of.
In the password file put something like /bin/true as the login shell.
In /etc/shells also put an entry for /bin/true so that ftp will work.
This will allow remote access and ftp (you will need to set a passwd
for this account!) to work without being able to login.
Set his login shell to a program or script that simply exits (e.g.
/bin/false). Add this to /etc/shells so that he'll be able to use FTP.
Thanks to the following:
stern@sunrise.east.sun.com (Hal Stern - NE Area Systems Engineer)
df5slsn@is000913.bell-atl.com (Hermida)
"Richard J. Niziak" <rickn@ma.copley.com>
Ian MacPhedran <Ian_MacPhedran@engr.usask.ca>
Dave Fetrow <fetrow@biostat.washington.edu>
chip@eniac.seas.upenn.edu (Charles "Chip" Buchholtz)
pamela@Legato.COM (Pamela Pledger)
brb@ike.safb.af.mil (SrA Bruce R Baier)
james mularadelis <jamesm@matrix.newpaltz.edu>
tap116@nocc.minsy.navy.mil (Tom Plesha)
Chris Wozniak TISC <chris@tisc.edu.au>
Dave O'Shea <dave_oshea@wiltel.com>
Richard Pieri <ratinox@unilab.dfci.harvard.edu>
tep@rzrbyte.neosoft.com (Tim Peoples)
rad@getech.leeds.ac.uk
"B.McCrone" <B.T.Mccrone@dl.ac.uk>
pburyk@leis.leis.bellcore.com (Patrick Buryk)
weitzel@burke.com (David Weitzel)
Mike Raffety <mike_raffety@il.us.swissbank.com>
Guy Polis <polis_guy@jpmorgan.com>
jtcummi@sandia.gov (Jeff Cummings)
"Patrick O'Callaghan" <poc@usb.ve>
James T Perkins <jamesp@sp-eug.com>
daryl@cs.athabascau.ca (Daryl Campbell)
Nate Itkin <Nate-Itkin@ptdcs2.intel.com>
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
Barry Margolin <barmar@Think.COM>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:07 CDT