lkml.org 
[lkml]   [2006]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Dumpable tasks and ownership of /proc/*/fd
Dear diary, on Mon, Apr 10, 2006 at 09:42:03AM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> The most straight forward is:
> int openat(int dirfd, const char *path, int flags, int mode)
> {
> int orig_dir_fd;
> int result;
> lock()
> orig_dir_fd = open(".");
> fchdir(dirfd);
> result = open(relpath);
> fchdir(orig_dir_fd);
> close(orig_dir_fd);
> unlock();
> return result;
> }
>
> I suspect something like the above needs to be considered if
> you want the emulation to work on old kernels, in the presence
> of suid applications.
>
..snip..
>
> Although I guess you could attempt to use /proc/self/fd/<n>
> and if that gets a permission problem try a slower but more
> reliable path in the emulation.

Oops, I completely forgot about fchdir(). Thanks, I think I will use
something like this for now.


By the way, I would like to return to a statement from your previous
mail:

> Other processes we do need to deny if we aren't dumpable because
> they don't have another way to get that information.

I still don't understand this - so why don't provide them _this_ way to
get that information? What is the security risk?

--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
-
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: 2006-04-11 15:44    [W:0.048 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site