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 be
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 pat
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 6
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
ore, but it is the _only_ uapi 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/linu
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 i
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 accom
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
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: se
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; \
> + } wh
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 a
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 rules
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 i
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 accom
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
>
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 dif
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, there
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 (D
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
(D
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-0
28 matches
Mail list logo