Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 9 Aug 2006 18:37:55 -0400 | From | Josef Sipek <> | Subject | Re: [RFC] Privilege escalation in filesystems |
| |
On Wed, Aug 09, 2006 at 06:17:32PM -0400, Trond Myklebust wrote: > On Wed, 2006-08-09 at 17:52 -0400, Josef Sipek wrote: ... > > (fs/nfs/nfs4recover.c:nfs4_save_user) > > current->fsuid = 0; > > current->fsgid = 0; > > This sort of thing can be defeated by selinux.
I was affraid of that.
> The right way to perform privileged operations is normally to give the > task to a kernel thread that has the required privileges (for instance a > work_queue like keventd).
This makes sense. So, I suppose it would make sense to have a per-mount or per-superblock pdflush-like thread that gets instantiated on mount.
> Ugh. Having the kernel interpret magic directory entries is just evil. > Having the kernel magically create and remove said entries on behalf of > the user ought to be punishable by death.
I'd like to hear about anything that is as portable, but not as "evil" :)
> Why can't you use something like an xattr to label opaqueness (or > visibility!) instead?
The goal is to have as few restrictions as possible - not every file system supports xattr.
Josef "Jeff" Sipek.
-- Bus Error: passangers dumped. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |