On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote:
> > According to patch description [1] and time_namespaces documentation
> > [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
> > and overhead in the kernel.
...
> > To be more specific - [if this were supported] it would
On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers
wrote:
> - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
> >
> > We are about to include the code signature required prior to restartable
> > sequences abort handlers into glibc, which will make this ABI
On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski wrote:
> From other discussion [4] - regarding the following system calls:
> time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm,
> getitimer, setitimer, select, utime, utimes, futimesat, and
> {old,new}{l,f,}stat{,64}.
>
> "These
Daniel Colascione wrote:
> >> If the kernel provides a system call, libc should provide a C wrapper
> >> for it, even if in the opinion of the libc maintainers, that system
> >> call is flawed.
I would like to state general support for this principle; in fact, I
seriously considered preparing
Daniel Colascione wrote:
> >> If the kernel provides a system call, libc should provide a C wrapper
> >> for it, even if in the opinion of the libc maintainers, that system
> >> call is flawed.
I would like to state general support for this principle; in fact, I
seriously considered preparing
On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann wrote:
> Most architectures now use the asm-generic copy of the sysvipc data
> structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
> __kernel_time_t on 32-bit architectures but have padding behind them to
> allow
On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann wrote:
> Most architectures now use the asm-generic copy of the sysvipc data
> structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
> __kernel_time_t on 32-bit architectures but have padding behind them to
> allow extending the type to
On Fri, Jun 2, 2017 at 3:12 PM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> On Fri, Jun 2, 2017 at 5:06 AM, Zack Weinberg <za...@panix.com> wrote:
>> On 06/02/2017 03:10 AM, Christoph Hellwig wrote:
>>>
>>> Can we please fix these conditionals s
On Fri, Jun 2, 2017 at 3:12 PM, Linus Torvalds
wrote:
> On Fri, Jun 2, 2017 at 5:06 AM, Zack Weinberg wrote:
>> On 06/02/2017 03:10 AM, Christoph Hellwig wrote:
>>>
>>> Can we please fix these conditionals so that only those
>>> relevant to Linux remain?
>
On 06/02/2017 03:10 AM, Christoph Hellwig wrote:
>
> Can we please fix these conditionals so that only those
> relevant to Linux remain?
I was going for the minimal change since this is dusty-deck code that I
can't practically test, but I have no objection to your more thorough
approach. I don't
On 06/02/2017 03:10 AM, Christoph Hellwig wrote:
>
> Can we please fix these conditionals so that only those
> relevant to Linux remain?
I was going for the minimal change since this is dusty-deck code that I
can't practically test, but I have no objection to your more thorough
approach. I don't
header that gets
this treatment, so IMHO it is worth patching just to drive that number
all the way to zero.
Signed-off-by: Zack Weinberg <za...@panix.com>
---
include/uapi/linux/a.out.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/a.o
header that gets
this treatment, so IMHO it is worth patching just to drive that number
all the way to zero.
Signed-off-by: Zack Weinberg
---
include/uapi/linux/a.out.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/a.out.h b/include/uapi/linux
This patch introduces with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers.
zw
Index: linux-2.6/include/linux/Kbuild
Here's yet another revision of the /proc/kmsg permissions patch
series. To recap, the point is to allow klogd to drop privileges
and continue reading from /proc/kmsg (currently, even if klogd has a
legitimately opened fd on /proc/kmsg, it cannot read from it unless
it has CAP_SYS_ADMIN asserted).
This patch breaks out the read operations in do_syslog() into their
own functions (klog_read, klog_readhist) and adds a klog_poll.
klog_read grows the ability to do a nonblocking read, which I expose
in the sys_syslog interface because there doesn't seem to be any
reason not to. do_syslog itself
Finally, add a new security class for access to /proc/kmsg, distinct
from the class used for the "read current messages" operations on
sys_syslog. The dummy and capability modules permit access to
/proc/kmsg to any user (who has somehow acquired an open fd on it);
SELinux is unchanged. This
As suggested by Stephen Smalley: map the various sys_syslog operations
to a smaller set of privilege codes before calling security modules.
This patch changes the security module interface! There should be no
change in the actual security semantics enforced by dummy, capability,
nor SELinux (with
Finally, add a new security class for access to /proc/kmsg, distinct
from the class used for the read current messages operations on
sys_syslog. The dummy and capability modules permit access to
/proc/kmsg to any user (who has somehow acquired an open fd on it);
SELinux is unchanged. This
As suggested by Stephen Smalley: map the various sys_syslog operations
to a smaller set of privilege codes before calling security modules.
This patch changes the security module interface! There should be no
change in the actual security semantics enforced by dummy, capability,
nor SELinux (with
This patch breaks out the read operations in do_syslog() into their
own functions (klog_read, klog_readhist) and adds a klog_poll.
klog_read grows the ability to do a nonblocking read, which I expose
in the sys_syslog interface because there doesn't seem to be any
reason not to. do_syslog itself
Here's yet another revision of the /proc/kmsg permissions patch
series. To recap, the point is to allow klogd to drop privileges
and continue reading from /proc/kmsg (currently, even if klogd has a
legitimately opened fd on /proc/kmsg, it cannot read from it unless
it has CAP_SYS_ADMIN asserted).
This patch introduces linux/klog.h with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers.
zw
Index: linux-2.6/include/linux/Kbuild
On 12/14/06, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> - (void) do_syslog(0,NULL,0);
> + (void) do_syslog(KLOG_CLOSE,NULL,0);
Please use a space after the commas (even though you just left it
as it already was).
Will change for the next revision.
zw
-
To unsubscribe from this list:
On 12/14/06, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> +#define security_syslog_or_fail(type) do { \
> + int error = security_syslog(type); \
> + if (error) \
> + return error; \
> + }
This patch introduces with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers. (Unlike the previous revision of this
patch series, no kernel-private
Here's a re-revised version of my patch set to allow klogd to drop
privileges and continue reading from /proc/kmsg (currently, even if klogd
has a legitimately opened fd on /proc/kmsg, it cannot read from it unless
it has CAP_SYS_ADMIN asserted). SELinux's pickier and finer-grained
privilege
As suggested by Stephen Smalley: map the various sys_syslog operations
to a smaller set of privilege codes before calling security modules.
This patch changes the security module interface! There should be no
change in the actual security semantics enforced by dummy, capability,
nor SELinux (with
This patch breaks out the read operations in do_syslog() into their
own functions (klog_read, klog_readhist) and adds a klog_poll.
klog_read grows the ability to do a nonblocking read, which I expose
in the sys_syslog interface because there doesn't seem to be any
reason not to. do_syslog itself
Finally, add a new security class for access to /proc/kmsg, distinct
from the class used for the "read current messages" operations on
sys_syslog. The dummy and capability modules permit access to
/proc/kmsg to any user (who has somehow acquired an open fd on it);
SELinux is unchanged. This
Finally, add a new security class for access to /proc/kmsg, distinct
from the class used for the read current messages operations on
sys_syslog. The dummy and capability modules permit access to
/proc/kmsg to any user (who has somehow acquired an open fd on it);
SELinux is unchanged. This
This patch breaks out the read operations in do_syslog() into their
own functions (klog_read, klog_readhist) and adds a klog_poll.
klog_read grows the ability to do a nonblocking read, which I expose
in the sys_syslog interface because there doesn't seem to be any
reason not to. do_syslog itself
As suggested by Stephen Smalley: map the various sys_syslog operations
to a smaller set of privilege codes before calling security modules.
This patch changes the security module interface! There should be no
change in the actual security semantics enforced by dummy, capability,
nor SELinux (with
Here's a re-revised version of my patch set to allow klogd to drop
privileges and continue reading from /proc/kmsg (currently, even if klogd
has a legitimately opened fd on /proc/kmsg, it cannot read from it unless
it has CAP_SYS_ADMIN asserted). SELinux's pickier and finer-grained
privilege
This patch introduces linux/klog.h with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers. (Unlike the previous revision of this
patch series, no
On 12/14/06, Randy Dunlap [EMAIL PROTECTED] wrote:
+#define security_syslog_or_fail(type) do { \
+ int error = security_syslog(type); \
+ if (error) \
+ return error; \
+ } while
On 12/14/06, Randy Dunlap [EMAIL PROTECTED] wrote:
- (void) do_syslog(0,NULL,0);
+ (void) do_syslog(KLOG_CLOSE,NULL,0);
Please use a space after the commas (even though you just left it
as it already was).
Will change for the next revision.
zw
-
To unsubscribe from this list: send
Linus Torvalds wrote:
> If somebody passes in a bad pointer to a system call, you've just
> invoced the rule of "the kernel _may_ be nice to you, but the kernel
> might just consider you a moron and tell you it worked".
>
> There is no "lost data" or anything else. You've screwed yourself, and
>
Linus Torvalds wrote:
If somebody passes in a bad pointer to a system call, you've just
invoced the rule of the kernel _may_ be nice to you, but the kernel
might just consider you a moron and tell you it worked.
There is no lost data or anything else. You've screwed yourself, and
you threw
On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote:
>
> Zack Weinberg writes:
> > It *has* been fixed in 2.4, though. Some sort of compatibility issue?
>
> No, some kind of "it doesn't matter" issue.
I can demonstrate user code that behaves di
On Tue, Jun 19, 2001 at 07:16:23PM -0700, David S. Miller wrote:
>
> Zack Weinberg writes:
> > The anonymous pipe code in 2.2 does not check the return value of
> > copy_*_user. This can lead to silent loss of data.
>
> I remember Andrew Tridgell (cc:'d) spottin
The anonymous pipe code in 2.2 does not check the return value of
copy_*_user. This can lead to silent loss of data.
The appended patch fixes the bug. It has been in continuous use on my
machine since May 13 (2.2.19) with no problems. It will apply to any
2.2 kernel from at least 2.2.18,
The anonymous pipe code in 2.2 does not check the return value of
copy_*_user. This can lead to silent loss of data.
The appended patch fixes the bug. It has been in continuous use on my
machine since May 13 (2.2.19) with no problems. It will apply to any
2.2 kernel from at least 2.2.18,
On Tue, Jun 19, 2001 at 07:16:23PM -0700, David S. Miller wrote:
Zack Weinberg writes:
The anonymous pipe code in 2.2 does not check the return value of
copy_*_user. This can lead to silent loss of data.
I remember Andrew Tridgell (cc:'d) spotting this a long time
ago, and we didn't
On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote:
Zack Weinberg writes:
It *has* been fixed in 2.4, though. Some sort of compatibility issue?
No, some kind of it doesn't matter issue.
I can demonstrate user code that behaves differently under 2.2 than
2.4. The example I
Kevin Buhr wrote:
> Jakob Østergaard <[EMAIL PROTECTED]> writes:
> >
> > Try compiling something like Qt/KDE/gtk-- which are really heavy on
> > templates (with all the benefits and drawbacks of that).
>
> Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three
> versions of GCC
Kevin Buhr wrote:
Jakob Østergaard [EMAIL PROTECTED] writes:
Try compiling something like Qt/KDE/gtk-- which are really heavy on
templates (with all the benefits and drawbacks of that).
Okay, I just compiled gtk-- 1.0.3 (with CFLAGS = "-O2 -g") under three
versions of GCC (Debian
On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Mar 2001, Zack Weinberg wrote:
> > 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
> > arrives after we've sent out the final ACK of the handshake. For
>
2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
arrives after we've sent out the final ACK of the handshake. For
example:
tcpdump: listening on eth0
15:15:15.075670 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
S 1057306555:1057306555(0) win 32120
2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
arrives after we've sent out the final ACK of the handshake. For
example:
tcpdump: listening on eth0
15:15:15.075670 wolery.Stanford.EDU.1341 plan9.bell-labs.com.www:
S 1057306555:1057306555(0) win 32120
mss
On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 15 Mar 2001, Zack Weinberg wrote:
2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
arrives after we've sent out the final ACK of the handshake. For
example:
Ah, that would explain
On Fri, Sep 01, 2000 at 03:56:40PM +1100, Keith Owens wrote:
> On Thu, 31 Aug 2000 21:44:16 -0700,
> Richard Henderson <[EMAIL PROTECTED]> wrote:
> >On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote:
> >> Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version
> >>
On Fri, Sep 01, 2000 at 03:56:40PM +1100, Keith Owens wrote:
On Thu, 31 Aug 2000 21:44:16 -0700,
Richard Henderson [EMAIL PROTECTED] wrote:
On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote:
Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version
2.96-ia64-000717 snap
53 matches
Mail list logo