lkml.org 
[lkml]   [1998]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support
   Date: 	Sun, 19 Apr 1998 14:22:08 -0700
From: Andrew Morgan <morgan@transmeta.com>

provide backwards compatability for legacy setuid applications. For
all the reasons that the capability model is a good one, making use of
'fE' is strongly discouraged. The obvious alternative to a single bit
of 'fE' capability is to have a complete multi-bit 'fE' set --
indicating which of the new process' permitted capabilities should
raised in the effective set. fE is defined to be one bit to strongly
discourage this "lack of programming" practice.

The tradeoff is that "lack of programming" allows people to start using
capabilities in systems without needing to modify the programs to
explicitly make system calls calls to raise their capability level. You
can simply set a program like inetd to have the
CAP_BSD_RESERVED_PORT_REALLY_BAD_IDEA capability, and you're done.

In the long run, it's better to explicitly make the programs explicitly
ask for capabilities, if for no other reason than to simplify the
configuration/management problem of having to manage all of the
capability bitfields on all of the executables on your system. But
there is the short-term implementation issue.

Given that 2.2 won't have the capability support in the filesystem
(sorry, I'll work on getting that into the ext2 filesystem during 2.3, I
promise!), this may be less of an issue, since we're going to need
programming changes in the user-side tools before we can really take
advantage of capabilities for real.

- Ted



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.091 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site