On Thu 2014-04-10 13:37:26, Andy Lutomirski wrote: > On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote: > >> > >> This is the second time in a week that someone has asked for a way to > >> have a struct file (or struct inode or whatever) that can't be reopened > >> through /proc/pid/fd. This should be quite easy to implement as a > >> separate feature. > > > > What I suggested on a different thread was to add the following new > > file descriptor flags, to join FD_CLOEXEC, which would be maniuplated > > using the F_GETFD and F_SETFD fcntl commands: > > > > FD_NOPROCFS disallow being able to open the inode via /proc/<pid>/fd > > > > FD_NOPASSFD disallow being able to pass the fd via a unix domain socket > > > > FD_LOCKFLAGS if this bit is set, disallow any further changes of FD_CLOEXEC, > > FD_NOPROCFS, FD_NOPASSFD, and FD_LOCKFLAGS flags. > > > > Regardless of what else we might need to meet the use case for the > > proposed File Sealing API, I think this is a useful feature that could > > be used in many other contexts besides just the proposed > > memfd_create() use case. > > It occurs to me that, before going nuts with these kinds of flags, it > may pay to just try to fix the /proc/self/fd issue for real -- we > could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is > read-only. That may be enough for the file sealing thing. Yes please. Current behaviour is very unexpected, and unexpected behaviour in security area is normally called "security hole". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html