Re: System Management Issues [was: Simplified UI (menu-systems)]

[Michael A Hamblin <michaelh@utdallas.edu>]

On Thu, 29 Apr 1999, Ian Bicking wrote:

> Do we want to segregate system configuration from other sorts?  
> I.e., would it be a good idea to let a person add users and groups, 
> but not devices or other, more dangerous stuff?  It would be nice to 
> let teachers manage a lot of information without having to worry if 
> they would unintentially mess up the computer.  (would sudo be 
> the way to deal with this?)

On Solaris there was a program called 'osh' that I used to use to operate
a printer on a machine I wasn't given root access to. I haven't thought
about it for a while b/c I haven't needed it (obviously I have root or
Adminstrator on all the boxes I manage now, or can get someone to fix it). 
But I did discover that osh (aka Operator Shell) is a rather interesting
program, in that it's very configurable. While I was using it to manage a
print que, it could be reconfigured to manage user accounts, reset
passwords, allow modifications of certain config files, etc. Groups and
stuff were configurable so that not just anyone could go in and run it,
and different operations could be given to different people (one person
could be allowed to delete/flush print jobs, another could be given only
access to modify basic account information, and another could be given
full user priveleges with creating/modifying/deleting users and resetting
passwords, and another can kill runaway processes).

I don't know of any simliar program in Linux though, and freshmeat didn't
turn up anything similiar (on a quick search that is). But if such a
program did exist, it would be benefitial. How many times have you seen CS
students try to print their output and don't check that their program
produced hundreds of pages of output? Give a trusted student osh
permissions and he can kill the print job -- even when a sub is in.

I'm sure that isn't QUITE what you had in mind ;) but I'm sure you can be
a little creative with this info.

Also, PAM modules are extremly powerful, I know McElroy has been using
them on DucTape to limit a lot of potential problems. There is a PAM
module we are using to limit the amount of processes, CPU time, and memory
a single user can use on DucTape, since it is a multi-user system. The
problem is that any person without limitations can write a C program like
this:

main() {
	malloc(1000000);
	fork();
}

and make the system completly unusable. Putting limitations in place can
make this problem less likely to occur or only occur in the user's account
space.

Another cool PAM module will allow you to authenticate users from an NT
domain, thus allowing the same password across NT and Linux/Unix
platforms. Thus you could have all your accounts on an NT box (rather, a
Linux box running SAMBA, that is how you are doing your NT serving,
right? :) and just authenticate against that.

While I've seen a lot of cool things done with PAM, I haven't actually
used it myself. I guess I ought to take a look and see what documentation
is available on it and see if it's applicable.

Lastly... does anyone know why ACLs haven't been implemented in Linux? I
might be stretching a bit, but sometimes it's useful for several ppl
(students) to collaborate in a shared directory, which means that ACLs
could be a handy thing. Keep common directories on a single NFS server and
run nightly backups on it.

--
Michael Hamblin            http://www.utdallas.edu/~michaelh/
michaelh@utdallas.edu      http://www.ductape.net/
UTD Linux User Group       Engineering and Computer Science Support x2997