FreeBSD Newbie Progress Day 5 (Making Progress)

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Totally Jayynes » Thu, 15 Nov 2001 06:27:38



Ok, I think I am getting somewhere (YEAH).  First of all, I am doing
all of this editing via ssh across a LAN, still pretty proud of myself
on that one :)

First of all, I edited  /usr/home/jay/.cshrc

so that my default editor is now ee and so my prompt tells my what
directory I am in.  Then I edited /.cshrc

So that when I su'd to root, my defualt editor would stay ee and also
that my command prompt stayed the same.  Now that I look at the
'locate cshrc', though, I think I should have edited /root/.cshrc just
for root.  By making changes to /.cshrc did I set some global options
for all future users?  Just verified that is what I did, su'd to root,
then changed /root/.cshrc so the prompt reads ROOT now, so I know when
I am root or not.

Then I was reading through the http://www.vmunix.com/fbsd-book/ (A
Comprehensive Guide to FreeBSD) and trying to follow along as I was
reading.  Opening up the config files and looking at the settings.
Well, when I  opened up /etc/inetd.conf I saw that ftp was commented
out.  Removed the #  and rebooted (have to learn how to start and stop
daemons, still).  After reboot, ran a netstat -Aan and saw that port
21 was listening, tried to ftp to my server... AND I COULD!!!!
WOOT!!!

Bad news is that when i did an ls, it showed me lots of files that I
probably don't want to have access to, or anyone else for that matter,
through ftp.  

A few people suggested using chroot, others said use Guest accounts.
Gotta figure out what to do next.  The sttructure I am looking for is
something like this.

/ftp (base directory when someone logs into my ftp
/ftp/music
/ftp/software
/ftp/upload

With other directories under those main directories... but the /ftp
being the root directory of the tree.
Totally Jayynes

 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Philip Paep » Thu, 15 Nov 2001 06:51:55


# -- snip snip -- #

Quote:> So that when I su'd to root, my defualt editor would stay ee and also
> that my command prompt stayed the same.  Now that I look at the
> 'locate cshrc', though, I think I should have edited /root/.cshrc just
> for root.  By making changes to /.cshrc did I set some global options
> for all future users?  Just verified that is what I did, su'd to root,
> then changed /root/.cshrc so the prompt reads ROOT now, so I know when
> I am root or not.

On a standard C-ish shell, the variable '%#' expands to the current 'best'
prompt to show on the command line.  As a user, you usually get a '%', and as
root, you get a '#'.  Here's a little quote from my .tcshrc (user and root):

 |?if ($?prompt) then
 |       # An interactive shell -- set some stuff up
 |       set color
 |       set filec
 |       set history = 100
 |       set savehist = 100
 |       set mail = (/var/mail/$USER)
 |       set promptchars = "%#"

 | endif

The above gives a user a command which looks like this:


For root, the 'prompt' variable should read:

 | set prompt = "(%m:%~)%# "

Which gives a prompt like:

 | (host:/path)#

The other variables which I set up (color <sic>, filec, histstory, etc etc)
are always nice to have.

Quote:> (have to learn how to start and stop daemons, still)

Try something like:

 |?# kill -1 `cat /var/run/inetd.pid`

Most d?mons make a 'pid* file in /var/run containing their process IDs.  You
could just read that file, and manually kill(1) each one, but that's
cumbersome.  Just cat(1) in the file, to pass the PIDs to kill(1) and all is
well.  The '-1' switch to kill(1) tells it to restart the process (SIGHUP),
rather than terminate (SIGTERM) it.  If you want to slaughter the process,
rather than restart it, you'd do 'kill -15', if it doesn't listen, you'll want
to use 'kill -9' (SIGKILL, very *).

Quote:> Bad news is that when i did an ls, it showed me lots of files that I
> probably don't want to have access to, or anyone else for that matter,
> through ftp.  
> A few people suggested using chroot, others said use Guest accounts.
> Gotta figure out what to do next.  The sttructure I am looking for is
> something like this.
> /ftp (base directory when someone logs into my ftp
> /ftp/music
> /ftp/software
> /ftp/upload
> With other directories under those main directories... but the /ftp
> being the root directory of the tree.

By default, a user starts in his $HOME (as defined in the password database),
you can lock him in there with a chroot(8) or a jail(8), in which case you'll
need to provide him with binaries like ls(1) and tar(1).  You can configure
ftpd(8) to take everyone to the same directory -- I think -- but I don't think
there's really a point in that.  Much more useful (humble opinion) to let
everyone FTP to their $HOME, and lock an 'anonymous' user in something like
/home/ftp.

 - Philip

--

  Most people want to be delivered from temptation but
  would like it to keep in touch.

 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Jed Clea » Thu, 15 Nov 2001 09:45:36



> Most d?mons make a 'pid* file in /var/run containing their process IDs.  You
> could just read that file, and manually kill(1) each one, but that's
> cumbersome.  Just cat(1) in the file, to pass the PIDs to kill(1) and all is
> well.  The '-1' switch to kill(1) tells it to restart the process (SIGHUP),

HUP stands for Hang UP.  It originally meant that the controlling
terminal phone line has hung up and that the process should take the
appropriate action.  I was going to say that getty might take it as a
restart signal, but I believe it exits and init restarts a new getty for
that tty.

Processes like init that don't have controlling terminals often catch
SIGHUP and re-read their configuration files.  However default action
for SIGHUP, like SIGTERM, is to terminate the process.  But either of
those can be caught and let the process do any specialized cleanup first
(e.g. lowering the control rods back into the reactor).  SIGKILL (-9)
doesn't give the process a chance to do anything special.

Unfortunately I know many at work that immediately whip out the BFG9000
and kill -9 everything.  Waste of good ammo, if ya ask me.

-Jed

 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Steve O'Hara-Smit » Thu, 15 Nov 2001 07:14:52


On Tue, 13 Nov 2001 14:27:38 -0700


> Ok, I think I am getting somewhere (YEAH).  First of all, I am doing
> all of this editing via ssh across a LAN, still pretty proud of myself
> on that one :)

        Nice one.

Quote:

> First of all, I edited  /usr/home/jay/.cshrc

> so that my default editor is now ee and so my prompt tells my what
> directory I am in.  Then I edited /.cshrc

> So that when I su'd to root, my defualt editor would stay ee and also
> that my command prompt stayed the same.  Now that I look at the
> 'locate cshrc', though, I think I should have edited /root/.cshrc just
> for root.  By making changes to /.cshrc did I set some global options

        You have bumped into a little gem here. They are (usually) both
the *same* file, edit either and both change. Files in UNIX are really
based at their inode number (essentially just a slot in an array of
all files in the filesystem) a directory is mostly a list of names with
associated inode numbers (the details get a bit more fiddly) so one
file can appear in many places on the filesystem, it is only deleted
when there are no directory entries left pointing at it and there
are no processes with it open.

        Look at the man page for dirent for the finer points.

        The whole directory system is essentially a convenience layer
to an array of files.

Quote:> out.  Removed the #  and rebooted (have to learn how to start and stop
> daemons, still).  After reboot, ran a netstat -Aan and saw that port

        Most daemons leave a file in /var/run called <name>.pid.

        Most daemons respond to a HUP signal by rereading their config
files and restarting - but some just die, it's woth cheking the man page.

        To send a HUP signal (or any other) use kill.

Quote:> Bad news is that when i did an ls, it showed me lots of files that I
> probably don't want to have access to, or anyone else for that matter,
> through ftp.  

        There is this about ftp - it is a cleartext protocol so the login
and all traffic can be seen. Contrary to early doctrine the safest use
of ftp is anonymous ftp. If you don't want to allow public access then
use scp. If you do then the ftpd man page has details of what you need
to do to set up anonymous ftp.

--
C:>WIN                                          |     Directable Mirrors
The computer obeys and wins.                    |A Better Way To Focus The Sun
You lose and Bill collects.                     |  licenses available - see:
                                                |   http://www.sohara.org/

 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Totally Jayynes » Thu, 15 Nov 2001 11:28:16




Quote:>By default, a user starts in his $HOME (as defined in the password database),
>you can lock him in there with a chroot(8) or a jail(8), in which case you'll
>need to provide him with binaries like ls(1) and tar(1).  You can configure
>ftpd(8) to take everyone to the same directory -- I think -- but I don't think
>there's really a point in that.  Much more useful (humble opinion) to let
>everyone FTP to their $HOME, and lock an 'anonymous' user in something like
>/home/ftp.

But I don't want a user to start in their home directory.  I want all
users to start in a central repository...  So user A can upload a song
in the /ftp/musci/uploads Directory and user B can log in and go to
that same directory to find it, not have to figure out which user
uploaded which file then try to find that users home directory.

On Tue, 13 Nov 2001 23:14:52 +0100, Steve O'Hara-Smith


>    There is this about ftp - it is a cleartext protocol so the login
>and all traffic can be seen. Contrary to early doctrine the safest use
>of ftp is anonymous ftp. If you don't want to allow public access then
>use scp. If you do then the ftpd man page has details of what you need
>to do to set up anonymous ftp.

Can't I create FTP accounts instead of creating User accounts that
have access to FTP?  I was under the assumption that was what a Guest
account was.  An account that only exists for FTP access.  So even if
someone did steal or sniff a password, the most damage they could do
is maybe delete files in areas that I allow that user to have file
deletion priveleges.  On any Windows FTP server I have ever run, I may
give users the ability to upload/create directories/or delete files in
certain areas, but in NO areas do I allow any users to run files
through FTP.  So again, the most damage a rogue ftp'er could do would
be to delete some files....  am I off base here or is this not
possible with a unix ftp?  Pretty simple with a Windows ftp, I use
BulletProof FTP for Windows.
Totally Jayynes
 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Steve O'Hara-Smit » Fri, 16 Nov 2001 05:28:30


On Tue, 13 Nov 2001 19:45:36 -0500


> Unfortunately I know many at work that immediately whip out the BFG9000
> and kill -9 everything.  Waste of good ammo, if ya ask me.

        That is just plain *bad*, kill -9 should be used as a last resort
*after* a SIGTERM has failed or when you *know* you don't want *any* cleanup
action. Otherwise it is far better in general to let programs do their
SIGTERM cleanups, they tend to be easier to get going again that way.

--
C:>WIN                                          |     Directable Mirrors
The computer obeys and wins.                    |A Better Way To Focus The Sun
You lose and Bill collects.                     |  licenses available - see:
                                                |   http://www.sohara.org/

 
 
 

FreeBSD Newbie Progress Day 5 (Making Progress)

Post by Steve O'Hara-Smit » Fri, 16 Nov 2001 05:58:45


On Tue, 13 Nov 2001 19:28:16 -0700


> But I don't want a user to start in their home directory.  I want all
> users to start in a central repository...  So user A can upload a song
> in the /ftp/musci/uploads Directory and user B can log in and go to
> that same directory to find it, not have to figure out which user
> uploaded which file then try to find that users home directory.

        You want anonymous ftp I think. Or do you want to prevent users
from affecting each others files ?

Quote:> Can't I create FTP accounts instead of creating User accounts that
> have access to FTP?  I was under the assumption that was what a Guest
> account was.  An account that only exists for FTP access.  So even if

        A 'Guest Account' can mean pretty much anything the sysadmin
wants it to in UNIX. All users are users with different things enabled.
If the shell is set to something invalid then log in isn't possible. If
the user is listed in /etc/ftpusers they cannot use ftp (yes that does
sound backwards). If there is a POP3 or IMAP server running they may
be able to fetch/manipulate email.

        The standard system ftpd does not support the concept of classes
of users. Wu-ftpd (and probably others) would allow you to group a set
of users such that they saw a common isolated area that all could read and
each user could only write on their own files. You can get pretty complex
setups going with this sort of thing.

Quote:> deletion priveleges.  On any Windows FTP server I have ever run, I may
> give users the ability to upload/create directories/or delete files in

        You can get very fine control with wu-ftpd (and probably others).

Quote:> certain areas, but in NO areas do I allow any users to run files
> through FTP.  So again, the most damage a rogue ftp'er could do would

        FTP does not allow execution at all.

Quote:> be to delete some files....  am I off base here or is this not
> possible with a unix ftp?  Pretty simple with a Windows ftp, I use

        The standard system ftpd only supports normal users, chrooted
users and the anonymous user. The ftpds in the ports support all sorts
of fancy things. It is also possible to do some quite amazing things by
running the ftpd itself in a chrooted environment or even a jail.

        Now that ssh is in the base system I would personally not be
bothered if ftpd were to be removed from the base system altogether.
OTOH stock ftpd is a useful tool on a LAN that can be trusted not to
be sniffed.

        It is a common UNIX trait to have tools that do what they do
very well and don't do anything not relevant to their main purpose on
the basis that there are other tools for doing that and they work well
together to provide more flexibility than you could ever build into a
single tool.

--
C:>WIN                                          |     Directable Mirrors
The computer obeys and wins.                    |A Better Way To Focus The Sun
You lose and Bill collects.                     |  licenses available - see:
                                                |   http://www.sohara.org/