Tuesday's questions

 "Dale S. Johnson" <dsj at merit.edu> writes:
  * Hi!
  * 
  *   Some assorted questions today:
  * 
  *   Can you confirm a couple of impressions?  1) That if we are running
  * without guarded attributes, then there is no code to prevent anyone
  * from changing anything.  However, whenever someone does change
  * something that they probably aren't supposed to, a mail message gets
  * sent to the people responsible for that object so the damage can
  * probably be quickly repaired.  2) That when we run with guarded ASs,
  * this really doesn't matter much for nets since the only information
  * about nets that is used in routing is their ASs (and those *are*
  * guarded).
  * 
Both right yes.

  *   I gather Marten would like us to hold off on using the guarded
  * attribute stuff until it is a bit more stable.  This would mean that
  * we'd put the first version into production unguarded.  Do we have
  * concensus that this is the right way to go for an initial deployment?
  *
We talked about here and there seems no porblem so please try it.
 
  *   What is the status of communities?  Laurent thought that they had
  * been announced as operational for Feb 7 (or some such).
  *
Communities are allowed and guarded in the same way. The only
difference in the software is the link for the database software
for cleandb.
 
  *   Is "rash" something you'd recommend we use?  Is the code available?
  *
Well, not really sure if I'd recommend it. It is just a chrooted thing
I got and changed a little. I'll enclose it but if you already have
ways of doing you chrooting then no problems. Of course, it is
entirely up to you if you want a secure login or not. We really need
it more for the fact that we ourselves may have things we don't 
really want the guardians to see rather than for any malicious type 
worries.


/*
 *  This is the initial "shell" for external users.
 *  Its function is to chroot to ROOT and exec SHELL.
 *  It also sets up the environment (HOME, SHELL, PATH,
 *  TERM and USER).
 *  It should be suid root for chroot to work.
 *                                                      JA 17-Oct-86
 *
 *
 *  Thanks to John Andrews for this. What are freinds for ??
 *
 *  
 */

/*
 * This is now known as rash
 * The restricted access shell ;-)
 * 
 * TB - 171193
 */

#include <stdio.h>


#define ROOT	"/home/guarded"
#define SHELL   "/bin/sh"       /* relative to new root */
#define PATH    ".:/bin"

#define MAXENV  100
#define EOS     '\0'
#define NIL     (char *) 0

char	minus[20] = "-";
char    en_shell[MAXENV] = "SHELL=";
char    en_home[MAXENV]  = "HOME=";
char    en_path[MAXENV]  = "PATH=";
char    en_user[MAXENV]  = "USER=";
char    en_term[MAXENV]  = "TERM=";
char    *envp[MAXENV];

main()
{
	char    *name, *rindex();
	char    *getenv(), *strcat();

	if( chroot(ROOT) == 0 ){
		setuid( getuid() );     /* become user */
		(void) chdir( getenv("HOME") );

		envp[0] = strcat(en_shell, SHELL);
		envp[1] = strcat(en_home, getenv("HOME"));
		envp[2] = strcat(en_path, PATH);
		envp[3] = strcat(en_user, getenv("USER"));
		envp[4] = strcat(en_term, getenv("TERM"));
		envp[5] = NIL;

		if(( name = rindex(SHELL, '/')) == NULL )
			name = SHELL;
		else
			name++;
		execle( SHELL, strcat(minus,name), 0, envp);
	}
	printf("Cannot login - please contact ncc at ripe.net\n");
	exit(0);
}
 
  *   We'd like to look at what would be required to add new attributes for
  * Merit purposes to our copy of the db.  Presumably we'd need to strip
  * these out of the db file that we transfer to you.  (Or would your code
  * just ignore new attributes in the .db file that it didn't know about?)
  * Could you suggest just a few sentences of issues we're likely to
  * encounter, code that you know offhand will require changing, things to
  * think about, etc?
  *
Well - the db software will just ignore them so it should be okay. The
interesting bit to remmeber is the extensions you need to add to
syntax.pl (blame me for that awful code) (if you want to syntax check
that it ?) and I would sugguest creating
your own syntax module that can be looked at. It is on the agenda to
make this a configurable type of syntax meta language but that 
wont be for a while.
 
  *   And a really vague one:  How much staff time do you spend "operating"
  * this?  (Or, more to the point, any estimates of what we need to budget
  * for operations?)  Even though this is a direct-user-input system, there
  * seems to be at least a minimal ongoing load to human process "auth:"
  * requests, set up new accounts, etc.  Are there routine issues that come
  * up with the nightly cleandb that end up requiring human involvement?
  * When two ASs claim the same net, do they tend to work that out
  * themselves (based on your automatic "conflict" email), or do you end up
  * participating in the discussion?  How much time does the RIPE NCC spend
  * helping new ASs or new net administrators learn the system and get
  * through problems?  How often do you have to go in as the administrators
  * and overwrite somebody's data?

This is a tricky one. Currently, we probably spend too much time on it
I would say as this is all still in the learning curve. The idea
behind all this is to eventually make the whole thing part of the
`core' service. Also, part of PRIDE is to educate the SPs to we 
will always spend time with them if they need.
On resolving problems - it is not too bad at the moment. The real plus
will be when we get the PRIDE guide out as this should take some of
the general misunderstandings off us.

As to resources it is hard to say but this is certainly at least two
FTE's to start with reducing to one I would say as the community
settles down to RRs and all things routing policy. 
 

  * 
  *   Do you recommend that Merit time be allocated for searching out
  * incomplete or incorrect information, and contacting people to
  * encourage them to do better at their registrations?  (e.g. how much
  * time do you spend doing that?  Should that be an operational responsibility
  * of a "remote RIPE" site?)
  *
Well - I spend the most time on this. At RIPE meetings I put up names 
of who hasn't registered. I even brought one SP a bottle of wine (out
of my own pcket) for his excellent additions. But seriously, it would
be great for you to push in this area. It is something we need as much
effort as possible.
 
  *   (And all of those activities, I presume, are in addition to figuring
  * out what next months' features ought to be, building concensus with the
  * community, actually coding and testing, answering long-winded questions
  * for friends across the pond, etc.  :-) )
  *
Sure.
 
  *   Thanks!
  * 
  * -Dale

-Tony



-------- Logged at  Fri Mar 11 14:47:47 MET 1994  ---------