Re: Unprivileged default user for "tiny" daemons?

locate.database is created by /etc/periodic/weekly/310.locate, isn't it?
It's behavior is run by nobody.

The other thing that is often forgotten is that the group behaves as if a setgid bit has been set up in the directory.

Is the idea that one daemon-specific user is sufficient, as long as setegid, seteuid, umask, fileowner, filepermission, and these settings are appropriate, out of date? :)


Yuri wrote on 2023/05/09 17:19:
> Brooks Davis wrote:
>> On Tue, May 09, 2023 at 10:05:15AM +0200, Felix Palmen wrote:
>>> * Felix Palmen <zirias@FreeBSD.org> [20230508 18:39]:
>>>> I tend to think now that 'daemon' should really be the way to go when
>>>> you don't need a dedicated account. Am I overlooking something? Any
>>>> other comments?
>>>
>>> Seems I overlooked something indeed:
>>>
>>> #v+
>>> $ find [14-jail] \( -user daemon -or -group daemon \)
>>> [14-jail]/usr/sbin/lpc
>>> [14-jail]/usr/bin/lprm
>>> [14-jail]/usr/bin/lpr
>>> [14-jail]/usr/bin/lpq
>>> [14-jail]/var/rwho
>>> [14-jail]/var/spool/mqueue
>>> [14-jail]/var/spool/lpd
>>> [14-jail]/var/spool/output
>>> [14-jail]/var/spool/output/lpd
>>> [14-jail]/var/spool/opielocks
>>> [14-jail]/var/at/jobs
>>> [14-jail]/var/at/spool
>>> [14-jail]/var/msgs
>>> #v-
>>>
>>> So, daemon owns e.g. the print spool...
>>>
>>> Interestingly, ou even find something owned by nobody in base:
>>>
>>> #v+
>>> -rw-r--r--  1 nobody  wheel  0 Jul  8  2021 /var/db/locate.database
>>> #v-
>>
>> This seems like a bug.
> 
> Indeed, it's even in BUGS section in locate(1) :)
> 
>  The locate database is typically built by user “nobody” and the
>  locate.updatedb(8) utility skips directories which are not readable for
>  user “nobody”, group “nobody”, or world.  For example, if your HOME
>  directory is not world-readable, none of your files are in the
>  database.
> 
>>>
>>> So, takeaway is: There is no safe choice other than allocating a
>>> dedicated UID for every single daemon, even if it doesn't need to
>>> own/access any files? Is this really correct?
>>
>> This is clearly the right choice even it's a bit of a pain.
> 
>