cvs commit: ports/audio/arts Makefile

[Eivind Eklund]

On Tue, Mar 02, 2004 at 10:53:57AM -0500, Brian F. Feldman wrote:
> Will Andrews <will at csociety.org> wrote:
> > On Tue, Mar 02, 2004 at 07:47:52AM -0600, Jacques A. Vidrine wrote:
> > > P.S.  I don't mean to pick on this port in particular.  I believe there
> > > are other ports that install set-user-ID binaries where it is not
> > > essential.  I just haven't had a chance to make a sweep of the tree yet
> > > to identify them.
> > 
> > I agree with Michael - I'd rather have working software than
> > a false sense of security, when it comes to desktop software.
> > 
> > If you are going to push a "make all setuid bits optional"
> > agenda, I suggest coming up with a standard means of letting the
> > administrator specify their policy regarding those.  You could
> > also offer alternate means of achieving the effect that set-id
> > wrappers/programs intend with their privileges.
> > 
> > Unfortunately, in arts' case, setpriority(2) is superuser-only.
> > Perhaps in FreeBSD 5, we should start implementing standard means
> > of allowing programs like artsd to call setpriority(2) without
> > privileges, e.g. through MAC.
> 
> Is it setpriority(2) or rtprio(2)?  The latter was implied,

It's sched_setscheduler().  I think it sets up a real time scheduler (it
looks like it), but the man page is not clear, and I'm not familiar with
it from before.

> and it is NOT acceptable to have ports use rtprio(2) without consent
> from the system administrator -- and not implicit consent, either.

It is inacceptable to have our desktop systems not work properly.
Desktop users is where we recruit a large fraction of our developers.

I think that the change in question looks safe (I've reviewed the
wrapper in question - the only two things that I'd have done differently
is move a printf to after dropping privileges, and just do a forced drop
of privileges instead of testing to see if it is necessary).  I also
think that wanting to have the users give explict OK is a worthy goal -
but this HAS to be doable globally, and it HAS to be obvious to the
users.  Perhaps a wrapper-wrapper would be the solution.

Barring that, I think that we should just review the wrappers really
carefully and keep the setuid bits.

Eivind.