[lkml]   [1999]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Capabilities, this time in elf section
Albert D. Cahalan writes:
> Richard Gooch writes:
> > Albert D. Cahalan writes:
> >> David L. Parsley writes:
> >>> Now, I have a suggestion that should apply equally to either solution; it
> >>> could be possible to specify in a mount option masks for permitted and
> >>> inheritable. This would limit the actual capabilites the mount would
> >>> honor. This could be nice for either implementation.
> >>
> >> This is great. It can not be supported by Richard Gooch's system though.
> >> I suppose one could scan the filesystem and then remount it.
> >
> > Sorry, I don't see why not.
> You wanted to insert code into the executable that would check for
> a capabilites section, instead of letting the kernel do the job.

Ah, I thought so. Yes, I did initially. I then changed my mind. The
kernel drops caps on exec.

> The kernel knows what the mount options were. Userspace has little
> clue what they were. You could add a system call for that or hope
> that /etc/mtab has the data you need. Both options are crummy.

Actually, I suspect that I could get it to work even in user
space. You're right, you'd need a special system call. But it's
getting a bit ugly, and the amount of code needed to support a user
space scheme would be about the same as the amount of code required to
just do it in the kernel. And the kernel space implementation would be
100% robust.

> Your solution offers full support on old kernels, but that breaks
> if you add a system call to check the mount options.

My (new) scheme provides both.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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