Messages in this thread | | | Date | Sat, 10 Apr 1999 12:31:32 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
On Sat, 10 Apr 1999, Steffen Zahn wrote:
> >>>>> "David" == David L Parsley (lkml account) <kparse@salem.k12.va.us> writes: > > David> With cap support directly in the FS, it won't work across NFS, > David> or after a cp, tar, cpio, what have you without modifying all > David> these tools. It also won't work on any other fs without cap > David> support. (of course) This solution has the nice property of > David> working _now_, (well, pending code obviously) and having great > David> compatibility with current Linux code. > > The content of executable files never carried around special > privileges in Unix, they are always stored in metadata. And never > are such privileges carelessly copied around.
Well, when I 'cp sendmail' as root, the resulting binary is setuit root. Maybe you misunderstand the idea: current fs's & tools don't support the notion of per-file capabilities, but they _do_ support the notion of 'setuid 0' which traditionally made a binary 'all-powerful'. With this scheme, we redefine the notion of 'setuid 0' to mean that a binary has some cap's raised, and stored in the elf headers.
The problem is, to get good semantics, there are a lot of repercussions which all need to be thought out. For instance, I now find that besides needing to store the true owner of the file in the headers, we also need to store the true value of the setuid bit, to determine whether the file actually executes as the owner or not. (group info is _not_ needed)
> Transfer of > privileges needs careful considerations and itself special > privileges. For example even if you can read /bin/login as a > normal user you can not copy its privilege with the file > content.
The same should definitely apply here; though if the user has capA & capB raised, the file should be allowed those. (this is why the actuall coding get's deep quick)
> The only reasonable approach is that all tools and > transfer protocols, that are not aware of capabilities, erase all > capabilities by default. This means that default behavior of > system calls (open,creat etc.) has to be set accordingly. This > also means that transfer protocols (NFS), that are not aware of > capabilities, do not transfer capabilities.
Currently the notion of 'setuid root' propagates all over _anyway_ if root is copying the file. This just puts a finer grain on the propagation of capabilities.
> Best regards > Steffen Zahn > > -- > home email: user@domain where domain=berlin.snafu.de, user=zahn > Use of my address for unsolicited commercial advertising is forbidden. > 2^3021377 - 1 | "Where do you want to crash today?" >
- -- David L. Parsley Network Specialist City of Salem Schools
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |