On 25/11/2013 16:14, Robert Millan wrote:
> On 25/11/2013 14:56, Petr Salinger wrote:
>> We still could preserve "struct session" size.
>
> That would break the expectation that MAXLOGNAME <= sizeof(s_login). Are
> you sure it's a good idea?
On second thought, this is getting too ugly and annoyin
On 25/11/2013 14:56, Petr Salinger wrote:
> We still could preserve "struct session" size.
That would break the expectation that MAXLOGNAME <= sizeof(s_login). Are
you sure it's a good idea?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
On 25/11/2013 14:56, Petr Salinger wrote:
> The getlogin_r is not thread safe, as it uses the same buffer as getlogin.
This should fix it, I think. It still updates the buffer (for the sake
of getlogin) but doesn't rely on it.
Also, I think the ERANGE check can be removed when we drop support for
together with revisisting
getlogin/getlogin_r/setlogin
I reviewed those functions and AFAICT the consequences are not terribly
bad (see my previous mail). Are there other concerns?
The getlogin_r is not thread safe, as it uses the same buffer as getlogin.
Thread A calls getlogin_r(), the __ge
On 25/11/2013 09:55, Petr Salinger wrote:
> together with revisisting
> getlogin/getlogin_r/setlogin
I reviewed those functions and AFAICT the consequences are not terribly
bad (see my previous mail). Are there other concerns?
> and dropping support for glibc
> compiled with "--enable-compatible-
I believe we can raise MAXLOGNAME, together with revisisting
getlogin/getlogin_r/setlogin and dropping support for glibc
compiled with "--enable-compatible-utmp" (the Debian one is compiled with
--disable-compatible-utmp anyway).
The problem might be with , but this header is
problematic-all-time
On 16/11/2013 17:26, Robert Millan wrote:
> See:
>
> http://svnweb.freebsd.org/base?view=revision&revision=243023
>
> Given that MAXLOGNAME is mirrored in and available to
> userland, this opens a few questions:
I've audited the getlogin / getlogin_r / setlogin family of functions.
My findings
Package: kfreebsd-10
Version: 10.0~svn257123-1
Severity: important
See:
http://svnweb.freebsd.org/base?view=revision&revision=243023
Given that MAXLOGNAME is mirrored in and available to
userland, this opens a few questions:
- Does the new ABI create any security concerns? E.g. buffer overflow
8 matches
Mail list logo