On Sat, 3 Nov 2012 18:29, ametz...@downhill.at.eu.org said:
comment sums it up:
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72
Well, it is the usual problem with inter-library dependencies. We will
never be able to get this right. The DSO is just not designed to work
On 2010-01-23 Andreas Metzler ametz...@downhill.at.eu.org wrote:
On 2010-01-23 Ansgar Burchardt ans...@2008.43-1.org wrote:
the function lock_pool from src/secmem.c has the side effect of changing
user ids if real uid != effective uid. This causes strange behaviour in
other programs:
A
Ansgar Burchardt ans...@43-1.org writes:
Werner Koch w...@gnupg.org writes:
On Mon, 25 Jan 2010 16:13, ans...@43-1.org said:
Yes, it is even quite simple to write such an application: Just call
getgroups(), getpwent(), ... on a system that uses LDAP. If there is no
caching daemon like
On Wed, 27 Jan 2010 01:17, ans...@43-1.org said:
There are enough sensible reasons for an application using gcrypt only
indirectly (eg. applications using gnutls should not need to care which
cryptographic library is used by it, more so for applications that only
use a library like libcurl
Hi,
Simon Josefsson si...@josefsson.org writes:
It can run in a separate process if nscd (glibc's name service caching
daemon) is running. But if nscd is not installed or not running for
some reason, there is not much to do except doing the query in the same
process.
Why can't the system
Ansgar Burchardt ans...@43-1.org writes:
Hi,
Simon Josefsson si...@josefsson.org writes:
It can run in a separate process if nscd (glibc's name service caching
daemon) is running. But if nscd is not installed or not running for
some reason, there is not much to do except doing the query
* Werner Koch:
That is a broken design. glibc should never ever allow suid processes
to run code from external services it is not 100% sure they are clean.
I guess libnss_files and the other standard ones might be fine, but LDAP
or even LDAPS are very problematic. Such code belongs into a
Werner Koch w...@gnupg.org writes:
On Mon, 25 Jan 2010 16:13, ans...@43-1.org said:
Yes, it is even quite simple to write such an application: Just call
getgroups(), getpwent(), ... on a system that uses LDAP. If there is no
caching daemon like nscd running, the application will use
Hi!
I understand that there is sometimes the need for lifetime long suid
programs. Although, I don't think that it is a sensible approach to
write software this way (instead of using helpers like userv), I can add
a hack to disable dropping of permissions.
Ansgar, is it that what you want?
Hi,
Werner Koch w...@gnupg.org writes:
I understand that there is sometimes the need for lifetime long suid
programs. Although, I don't think that it is a sensible approach to
write software this way (instead of using helpers like userv), I can add
a hack to disable dropping of permissions.
On Mon, 25 Jan 2010 14:24, ans...@2008.43-1.org said:
Yes, that is fine with me. Changing the default may break assumptions
made by existing applications after all.
Of course we will not change the default.
It would be nice if the documentation could mention that libraries that
initialize
Werner Koch w...@gnupg.org writes:
Are you trying to tell us that there is an application with dependencies
to libnss, openldap and gnutls and that one is intended to be run suid?
Did you audit all that code and the way the code is used to be written
properly in a way that the suid-ness is
On Mon, 25 Jan 2010 16:13, ans...@43-1.org said:
Yes, it is even quite simple to write such an application: Just call
getgroups(), getpwent(), ... on a system that uses LDAP. If there is no
caching daemon like nscd running, the application will use libnss-ldap
(via glibc's Name Service
On 2010-01-23 Ansgar Burchardt ans...@2008.43-1.org wrote:
the function lock_pool from src/secmem.c has the side effect of changing
user ids if real uid != effective uid. This causes strange behaviour in
other programs:
A program using libnss-ldap for querying group membership with SSL
Package: libgcrypt11
Version: 1.4.4-6
Severity: normal
Hi,
the function lock_pool from src/secmem.c has the side effect of changing
user ids if real uid != effective uid. This causes strange behaviour in
other programs:
A program using libnss-ldap for querying group membership with SSL
15 matches
Mail list logo
