[arch-dev-public] [arch-general] [signoff] syslog-ng-3.0.1-1

[Allan McRae]

Gerardo Exequiel Pozzi wrote:
> Tobias Powalowski wrote:
>   
>> Am Mittwoch 11 März 2009 schrieb Allan McRae:
>>   
>>     
>>> Gerardo Exequiel Pozzi wrote:
>>>     
>>>       
>>>> Pierre Schmitz wrote:
>>>>       
>>>>         
>>>>> Does anybody know what this message in dmesg is about? Was syslog-ng
>>>>> compiled for i686?
>>>>>
>>>>> warning: `syslog-ng' uses 32-bit capabilities (legacy support in use)
>>>>>         
>>>>>           
>>>> Very out-of-date libcap, not only syslog-ng, also proftpd, vsftpd,
>>>> pulseaudio, ntpd, virtualbox, etc, etc...
>>>>
>>>> http://www.archlinux.org/packages/extra/i686/libcap/ (for linux 2.4)
>>>>
>>>> Need to have libcap2 package for kernel 2.6 in Arch Linux
>>>> http://www.kernel.org/pub/linux/libs/security/linux-privs/
>>>>       
>>>>         
>>> I was confused about this as libcap is in [extra] so how can it make
>>> problems with a package in [core]?
>>>
>>> So going from this comment in the bug report about libcap
>>> (http://bugs.archlinux.org/task/11917#comment41046) I get...
>>>
>>>     
>>>       
>>>> readelf -s /usr/sbin/syslog-ng | grep cap
>>>>       
>>>>         
>>>     33: 00000000     0 FUNC    GLOBAL DEFAULT  UND capset at GLIBC_2.1 (4)
>>>    177: 00000000     0 FUNC    GLOBAL DEFAULT  UND capget at GLIBC_2.1 (4)
>>>    473: 08228bd8     4 OBJECT  GLOBAL DEFAULT   26 OPENSSL_ia32cap_P
>>>
>>> Looks like libcap is a soft dep there.  How?
>>>
>>> Then rebuild in clean chroot:
>>>     
>>>       
>>>> readelf -s syslog-ng | grep cap
>>>>       
>>>>         
>>>    467: 08221b18     4 OBJECT  GLOBAL DEFAULT   26 OPENSSL_ia32cap_P
>>>
>>> And then the dmesg warning goes away...  So, the lesson to learn is to
>>> _always build in a clean chroot_!
>>>
>>> Allan
>>>     
>>>       
>> hrm i normally build in chroots, seems somehow this one slipped into it.
>> Shall i add it as makedepend?
>>
>>   
>>     
> Yes, is a makedepends, capget, capset are glibc symbols.
>
> But these symbols are defined in sys/capability.h (that are part of
> libcap) don't confuse with linux/capability.h
>
> So you can make syslog-ng with capabilities, and don't have libcap
> installed. ;)
>
> See libc.so ;)
> # readelf -s /lib/libc.so.6 | grep cap
>   1745: 000d10e0    67 FUNC    GLOBAL DEFAULT   11 capset@@GLIBC_2.1
>   1923: 000d1090    67 FUNC    GLOBAL DEFAULT   11 capget@@GLIBC_2.1
>   3801: 000d1090    67 FUNC    LOCAL  DEFAULT   11 __GI_capget
>   4043: 000d10e0    67 FUNC    LOCAL  DEFAULT   11 __GI_capset
>   5388: 000d10e0    67 FUNC    GLOBAL DEFAULT   11 capset
>   6337: 000d1090    67 FUNC    GLOBAL DEFAULT   11 capget
>
>
> Allan: I hope you have cleared up the confusion.
>   

Not really.....  so I did some research.  Here we go:

 From the release announcement for syslog-ng OSE 3.0:

 * support for capabilities under Linux, this running syslog-ng as 
non-root is possible,
   also with reload support, see the documentation of Linux capabilities 
in capabilities(7),
   for the syntax of the --caps option, see cap_from_text(3)

And from capabilities(7):

For the purpose of performing permission checks, traditional Unix 
implementations distinguish two categories of processes: /privileged/ 
processes (whose effective user ID is 0, referred to as superuser or 
root), and /unprivileged/ processes (whose effective UID is non-zero). 
Privileged processes bypass all kernel permission checks, while 
unprivileged processes are subject to full permission checking based on 
the process's credentials (usually: effective UID, effective GID, and 
supplementary group list).

So my conclusion is that it would probably be a good idea to add the 
makedepends on libcap.

Allan