On Sun, Mar 14, 1999 at 06:12:05PM -0500, Scott Schwartz wrote:
> Brad Shelton <[EMAIL PROTECTED]> writes:
> | On Sun, Mar 14, 1999 at 04:59:24PM -0500, Scott Schwartz wrote:
> | > Mate Wierdl <[EMAIL PROTECTED]> writes:
> | > | What mean things can happen if a user pipes the message to a command?
> | > | They can always do it using the shell anyways. The shell started in
> | > | .qmail is run by the user...
> | >
> | > But it might be running on the mail server, where users cannot
> | > normally log in, and where you only want to let them
> | > run certain commands.
> |
> | So script the .qmail creation for each user to be locked down by root
> | permissions.
> |
> | What's the big deal?
>
> That's a big complicated change. In my environment, which I think is
> typical, .qmail files are in home directories. Even if you have a
> seperate mail partition, it's simplest and easiest to allow users to
> create .qmail files using normal shell commands like vi. The issue
> isn't that we want to restrict .qmail files, but that we might want to
> restrict the commands that are executed on a particular cpu on behalf
> of them. That correctly handles the problem in all cases, with no
> ad-hoc restrictions on other kinds of delivery. Thus, the restricted
> shell solution is the right one.
Oh. Sorry. I didn't know there was a "right one".
I thought it went something like, "Use what works for your environment.
That's why it's modular and flexible. Use at your own risk."
If I have a system that I don't want users, except in special cases, to have
the ability to put whatever they feel like in their .qmail files. you better
believe I'll do whatever I have to do, to stop them.... if I have to.
It sounded to me as if he needed (in this case) to stop users from doing so.
Simple. Disable the ability. Of course, that causes the need for him to do
the admin if something needs to be changed.
His decision. Not ours.
--
Brad Shelton [EMAIL PROTECTED]
On Line Exchange http://ole.net
Detroit News http://detnews.com
