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

Aaron Griffin aaronmgriffin at gmail.com
Wed Mar 11 11:21:00 EDT 2009


On Wed, Mar 11, 2009 at 3:00 AM, Allan McRae <allan at archlinux.org> wrote:
> 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.

Then we should probably upgrade libcap first


More information about the arch-dev-public mailing list