lkml.org 
[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] unprivileged mounts update
Quoting Miklos Szeredi (miklos@szeredi.hu):
> > Right, I figure if the normal action is to always do
> > mnt->user = current->fsuid, then for the special case we
> > pass a uid in someplace. Of course... do we not have a
> > place to do that? Would it be a no-no to use 'data' for
> > a non-fs-specific arg?
>
> I guess it would be OK for bind, but not for new- and remounts, where
> 'data' is already used.
>
> Maybe it's best to stay with fsuid after all, and live with having to
> restore capabilities. It's not so bad after all, this seems to do the
> trick:
>
> cap_t cap = cap_get_proc();
> setfsuid(uid);
> cap_set_proc(cap);
>
> Unfortunately these functions are not in libc, but in a separate
> "libcap" library. Ugh.

Ok, are you still planning to nix the MS_SETUSER flag, though, as Eric
suggested? I think it's cleanest - always set the mnt->user field to
current->fsuid, and require CAP_SYS_ADMIN if the mountpoint->mnt->user !=
current->fsuid.

-serge
-
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/

\
 
 \ /
  Last update: 2007-04-26 17:01    [W:0.271 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site