diff mbox

[2/2] package/nut: specify --with-user/group when building NUT

Message ID 20170608153557.30726-1-mail@jens-maus.de
State Superseded
Headers show

Commit Message

Jens Maus June 8, 2017, 3:35 p.m. UTC
This commit fixes a problem where the NUT package couldn't be
used as a NUT server due to the fact that the default group for
nobody is "nogroup" and not "nobody" like the internal default
of NUT. Thus, when starting a NUT server daemon the daemon starts
with incorrect group permissions and generated some error messages.
This commit fixes this shortcoming by specifying --with-user/group
when running configure.

Signed-off-by: Jens Maus <mail@jens-maus.de>
---
 package/nut/nut.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Yann E. MORIN June 8, 2017, 7:20 p.m. UTC | #1
Jens, All,

On 2017-06-08 17:35 +0200, Jens Maus spake thusly:
> This commit fixes a problem where the NUT package couldn't be
> used as a NUT server due to the fact that the default group for
> nobody is "nogroup" and not "nobody" like the internal default
> of NUT. Thus, when starting a NUT server daemon the daemon starts
> with incorrect group permissions and generated some error messages.
> This commit fixes this shortcoming by specifying --with-user/group
> when running configure.
> 
> Signed-off-by: Jens Maus <mail@jens-maus.de>
> ---
>  package/nut/nut.mk | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/package/nut/nut.mk b/package/nut/nut.mk
> index 332ccf907..ab8a17868 100644
> --- a/package/nut/nut.mk
> +++ b/package/nut/nut.mk
> @@ -18,7 +18,9 @@ NUT_AUTORECONF = YES
>  # since the default location (/var/state/ups) maybe readonly.
>  NUT_CONF_OPTS = \
>  	--with-altpidpath=/var/run/upsd \
> -	--without-hal
> +	--without-hal \
> +	--with-user=nobody \

'nobody' is the default for the user, so it does not seem to be needed
to specify it, as we do have nobody. Being explicit is probably better.

> +	--with-group=nogroup

Yup.

Note however that nut does not recommend running as nobody/nogroup.

Instead, I would suggest we do add a user definition for nut, and
use that for configure.

    define NUT_USER
        nut -1 nut -1 * - - - Nut user
    endef

Regards,
Yann E. MORIN.

>  # For uClibc-based toolchains, nut forgets to link with -lm
>  ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
> -- 
> 2.11.0
>
Jens Maus June 10, 2017, 7:04 a.m. UTC | #2
Hi Yann, All,

> Am 08.06.2017 um 21:20 schrieb Yann E. MORIN <yann.morin.1998@free.fr>:
> 
> On 2017-06-08 17:35 +0200, Jens Maus spake thusly:
>> This commit fixes a problem where the NUT package couldn't be
>> used as a NUT server due to the fact that the default group for
>> nobody is "nogroup" and not "nobody" like the internal default
>> of NUT. Thus, when starting a NUT server daemon the daemon starts
>> with incorrect group permissions and generated some error messages.
>> This commit fixes this shortcoming by specifying --with-user/group
>> when running configure.
>> 
>> Signed-off-by: Jens Maus <mail@jens-maus.de>
>> ---
>> package/nut/nut.mk | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/package/nut/nut.mk b/package/nut/nut.mk
>> index 332ccf907..ab8a17868 100644
>> --- a/package/nut/nut.mk
>> +++ b/package/nut/nut.mk
>> @@ -18,7 +18,9 @@ NUT_AUTORECONF = YES
>> # since the default location (/var/state/ups) maybe readonly.
>> NUT_CONF_OPTS = \
>> 	--with-altpidpath=/var/run/upsd \
>> -	--without-hal
>> +	--without-hal \
>> +	--with-user=nobody \
> 
> 'nobody' is the default for the user, so it does not seem to be needed
> to specify it, as we do have nobody. Being explicit is probably better.
> 
>> +	--with-group=nogroup
> 
> Yup.
> 
> Note however that nut does not recommend running as nobody/nogroup.
> 
> Instead, I would suggest we do add a user definition for nut, and
> use that for configure.
> 
>    define NUT_USER
>        nut -1 nut -1 * - - - Nut user
>    endef

Thanks for your comments. Indeed I could remove —with-user=nobody from my patchset. And of course it would be better to run NUT with a new user. But IMHO for the time being the patch I submitted should be sufficient and we can apply an additional patch later. Or is my patch rejected now and I need to rework it for being accepted? Sorry for asking, but I am fairly new to submitting patches to buildroot and I am not fully confident to the procedure. In addition, I cannot see my initial patch at patchwork anymore?!?!

regards,
jens
Yann E. MORIN June 10, 2017, 7:21 a.m. UTC | #3
On June 10, 2017 9:04:47 AM GMT+02:00, Jens Maus <mail@jens-maus.de> wrote:
[snip]
> Thanks for your comments. Indeed I could remove —with-user=nobody from
> my patchset. And of course it would be better to run NUT with a new
> user. But IMHO for the time being the patch I submitted should be
> sufficient and we can apply an additional patch later. Or is my patch
> rejected now and I need to rework it for being accepted?

Yes, please resubmit your patch that defines a nut user, and uses
that during configure.

Keep both --with-user and --with-group.

> Sorry for
> asking, but I am fairly new to submitting patches to buildroot and I am
> not fully confident to the procedure.

No problem. You did correct so far. :-)

> In addition, I cannot see my
> initial patch at patchwork anymore?!?!

Indeed, because it was marked "changes requested".

Regards,
Yann E. MORIN..

Jens, All,
diff mbox

Patch

diff --git a/package/nut/nut.mk b/package/nut/nut.mk
index 332ccf907..ab8a17868 100644
--- a/package/nut/nut.mk
+++ b/package/nut/nut.mk
@@ -18,7 +18,9 @@  NUT_AUTORECONF = YES
 # since the default location (/var/state/ups) maybe readonly.
 NUT_CONF_OPTS = \
 	--with-altpidpath=/var/run/upsd \
-	--without-hal
+	--without-hal \
+	--with-user=nobody \
+	--with-group=nogroup
 
 # For uClibc-based toolchains, nut forgets to link with -lm
 ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)