[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: eviacam

Hi Cesar,

On Wed, 2011-08-03 at 13:22 +0200, Cesar Mauri wrote:
> > [...]
> >>> or so and move the SUID bit setting including creating a
> >>> group to postinst so that you limit the impact to an acceptable minimum.
> >>> Having an open root access for everybody on a system is quite a bit
> >>> too generous IMHO.
> >>
> >> I don't like also having a SUID binary but it is the only way I
> >> found to raise the priority of the process. I've moved the "chmod"
> >> to the postinst script but I couldn't create a group to setuid to
> >> because the nice system call (see nice(2)) needs superuser
> >> privileges.
> >
> > I seem to have not expressed my idea correctly:
> > - Have your binary chmod 4750
> > - with uid 0 (thus the setUID) and
> > - group "whateveryournewgroupname"
> >
> > In debian/postinst that would look like:
> > chmod 4750 $BINARY
> > chown 0:$GID $BINARY
> >
> > where $GID is the group id of the group you create in postinst.
> >
> > That will make sure it gets the UID 0 correctly so that nice(2) will work ok
> > and also will make sure that only users of the group are allowed to execute
> > it.
> >
> > Does that make sense for you?
> Got it! Before creating a new group, is there any previously existing 
> group that would be suitable for such a job (i.e. that a common desktop 
> user would be part of)?

None that would fit the requirements we have here IMHO.

> I think that if we need to create a new group may be some non-expert 
> users won't be able to run eviacam properly (i.e. they might fail to add 
> their username to such group). Other options include:
> i) ask the user whether to make eviacamloader SUID and explain that a 
> new group is needed and such and such.

Can be done with debconf quite easily as:
a) Ask whether SUID should be activated
b) which users should be added to the group interactively

Please set sensible defaults so that you can also work with

> ii) completely get rid of the SUID thing at the expense of less 
> responsiveness.

If that's possible and doesn't limit core functionality it sounds like a
valid option. What downsides would that bring?

I think debconf as explained above together with properly adding a new
group and importing users through debconf would be a good thing.

Best regards,

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: