Re: [dev] [slock] chown to root:root on install?

From: hiro <23hiro_AT_gmail.com>
Date: Wed, 9 Sep 2015 01:05:16 +0200

I propose throwing out all that "standards" crap like shadow files and
so on. There are already multiple ways implemented, whereas others are
missing.
I tried slock on a computer with some crazy network credential system
and entering a password results in segfault when the network has an
outage. It's horrible.

On 9/8/15, Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
> Heyho Nick,
>
> Nick wrote:
>> Ideally slock should always be owned by the root user, so that it can
>> disable
>> the oom lock. I wonder what the right solution is here, as obviously one
>> can't
>> chown a file to be owned by root if one isn't root oneself.
>>
>> One option would be to add a line like this to the install rule of the
>> makefile:
>>
>> _AT_chown root:root ${DESTDIR}${PREFIX}/bin/slock || echo "Could not chown
>> root:root ${DESTDIR}${PREFIX}/bin/slock; please do this manually"
>>
>> Or else add a note to the readme that the make install rule should be run
>> as
>> root. I am not in the habit of installing software outside of $HOME, so I
>> don't tend to think about elevating to root to install software, so this
>> initially confused me.
>
> I think the echo on chown fail is a good solution. If no one has a better
> idea,
> I'll fix that later today.
>
> On a side note: I think capabilities are the safer approach than the suid
> bit.
> However they are not supported by all filesystems. I propose to rename the
> install target to `install_suid` and add a new default `install` target
> which
> uses capabilities.
>
> --Markus
>
>
Received on Wed Sep 09 2015 - 01:05:16 CEST

This archive was generated by hypermail 2.3.0 : Wed Sep 09 2015 - 01:12:09 CEST