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 DEBCONF_FRONTEND=noninteractive > 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, Kilian
Attachment:
signature.asc
Description: This is a digitally signed message part