This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C11 threads ABI questions - enum values


On Sun, Oct 05, 2014 at 11:49:13AM +0200, Christoph Hellwig wrote:
> On Sat, Oct 04, 2014 at 06:57:56PM -0400, Rich Felker wrote:
> > The symlink thing is easy to do, but the permissions thing is hard.
> > O_PATH does not open the actual file at all, just a reference to the
> > inode. It would be easy to just reject the open request if +x
> > permission is not available at open time, but the hard part is making
> > the +x permission stick at open time in the case where it's removed
> > from the underlying file after the open takes place. It would take
> > help from someone who knows the kernel internals a lot better than me
> > to make this work.
> 
> The kernel uses FMODE_* flags on file->f_mode for that.  There are
> is no FMODE_EXEC right now, but it can be added along the lines of
> FMODE_READ/FMODE_WRITE trivially.  If you need more detailed help
> feel free to contact me off list.

OK I'll look at it.

> > My thought is that O_SEARCH and O_EXEC should probably be defined as
> > 3|O_PATH, but _not_ treated as O_PATH on the kernel side. Instead,
> > having the O_PATH bit set on top of the "secret" access mode 3 should
> > behave more like normal access mode 3, but with the usual permission
> > checks bypassed and replaced by checks for +x, and this +x access
> > right should be kept with the open file description. The reason for
> > using 3|O_PATH then is not to get O_PATH semantics, but for a graceful
> > fallback on older kernels that lack real O_SEARCH/O_EXEC support:
> > O_PATH is a reasonably close emulation, and old kernels will ignore
> > the access mode bits (3) when O_PATH is set.
> 
> Well, O_SEARCH and O_EXEC is very similar to O_PATH, so I would
> treat it conceptually the same, that is make fdget fail on file
> descriptors opened on it, and thus make all the normal operations
> impossible with a high level exclusion.  It would suggest to initially
> allow the additional operations like chown for all O_PATH descriptors.

Yes, the lack of support for fchown, fchmod, fstat, fstatfs, fchdir,
and perhaps others on O_PATH file descriptors is another problem with
using O_PATH outright. In musl I have fallback support that uses
/proc/self/fd/%d for these operations when the initial syscall fails
with EBADF despite being a valid file descriptor, but it would be nice
if the kernel just supported them directly. Is it reasonably easy to
add support for O_PATH file descriptors on the kernel side? If not,
that would be an indication that O_EXEC/O_SEARCH should perhaps not
work like O_PATH but "actually open the file".

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]