[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vacation and shell-less accounts
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: vacation and shell-less accounts
- From: Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>
- Date: Wed, 30 Oct 2002 01:25:39 -0500
> None of my users that get mail off of my systems have shell accounts - the
> standard /dev/null or some other such replacement has been used in the
> In order to get the vacation program to work - it seems that it needs a shell
> account - so that the program can be executed when the .forward file gets hit.
> How do you guys handle this? I have a user who needs me to set this up
> for her ASAP (which translates to yesterday in this case) And something simple
> seems to be more complex than I first assumed.
How would *I* handle it? I'd give my users full shell access. But I'm
a trusting kind of guy.
For you - I think you need to think, very carefully, just what kind of
access you do and do not want to give your users. Then you'll need to
go through the requisite software and see what's involved in giving
your users just that access.
The simple answer is you could just add whatever shell you've given
your users to /etc/shells. That will cause "usershellok" to return
true, which will allow execution of commands in .forwards. Of course,
if you're giving users the ability to modify their own filespace, they
could then modify .forward to contain arbitrary shell commands, which
they could use to leverage gaining full shell access, which makes your
efforts to restrict what they do not so useful. You might be
able to counter-act this, in part, by using systrace.
A more complicated answer would be to modify sendmail to permit finer
grained control over who can do what. For instance, you might want to
replace usershellok with something that takes the username & script
name, and returns true if the person is allowed to execute that thing -
which in case might be that anyone with a shell listed in /etc/shells
is allowed to do "anything", and everyone else can run a set list of
programs, including vacation.
The reason why this is complex is because you're fighting "the Unix
philosophy". That is, Unix is designed around the notion of mostly
simple tools that can easily work together in arbitrary ways to solve
problems. You are taking some of those simple tools and drawing a more
or less arbitrary line through them, and insisting users can be kept on
one side of that line. This means you have to look at everything that
can cross that line, and fix it to behave as you want, which is going
to be hard because none of the tools is designed to do quite what you