From owner-freebsd-emulation Mon Apr 23 22: 6:19 2001 Delivered-To: freebsd-emulation@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8478537B446; Mon, 23 Apr 2001 22:06:12 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3O56hf09636; Tue, 24 Apr 2001 01:06:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 24 Apr 2001 01:06:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: des@FreeBSD.org Cc: emulation@FreeBSD.org Subject: linprocfs and jail(8) interactions with Linux readdir()/ls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org DES, I've been playing a bit with running a complete Linux environment under jail(8), and have been bumping into a few nits (and attempting to fix them as I bump into them). One of them is that it appears that there are unfortunate interactions between linprocfs_readdir() and its p_can(...P_CAN_SEE...) invocation. When I run outside of the jail, it works fine, but from within the jail, linprocfs_readdir() returns the static entries, but no process entries: curry:/proc# ls -l total 0 -r--r--r-- 1 root root 0 Apr 24 05:03 cmdline -r--r--r-- 1 root root 0 Apr 24 05:03 cpuinfo -r--r--r-- 1 root root 0 Apr 24 05:03 devices -r--r--r-- 1 root root 0 Apr 24 05:03 meminfo dr-xr-xr-x 1 root root 0 Apr 24 05:03 net lr--r--r-- 1 root root 0 Apr 24 05:03 self -> 22359 -r--r--r-- 1 root root 0 Apr 24 05:03 stat -r--r--r-- 1 root root 0 Apr 24 05:03 uptime -r--r--r-- 1 root root 0 Apr 24 05:03 version curry:/proc# I can perform lookups on the right and wrong processes with appropriate results: curry:/proc# ps x PID TTY STAT TIME COMMAND 22360 ? 0 0:00 ps x 20030 ? 0 0:00 /bin/bash curry:/proc# ls 1/ ls: 1/: No such file or directory curry:/proc# ls 20030/ cmdline exe mem stat status curry:/proc# What appears to be happening is that when p_can() returns a failure, a short read is returned from readdir() (although it's not the end of file). The linux version of ls (or possibly the library) seems to return in that case, whereas the FreeBSD ls handles this fine: curry:/proc# /fbsdbin/ls -l total 0 dr-xr-xr-x 1 0 root 0 Apr 24 05:05 20030 dr-xr-xr-x 1 0 root 0 Apr 24 05:05 22375 -r--r--r-- 1 0 root 0 Apr 24 05:05 cmdline -r--r--r-- 1 0 root 0 Apr 24 05:05 cpuinfo -r--r--r-- 1 0 root 0 Apr 24 05:05 devices -r--r--r-- 1 0 root 0 Apr 24 05:05 meminfo dr-xr-xr-x 1 0 root 0 Apr 24 05:05 net lr--r--r-- 1 0 root 0 Apr 24 05:05 self -> 22375 -r--r--r-- 1 0 root 0 Apr 24 05:05 stat -r--r--r-- 1 0 root 0 Apr 24 05:05 uptime -r--r--r-- 1 0 root 0 Apr 24 05:05 version curry:/proc# I'm not sure what the right fix for this is--on face value, it would seem to be that when an entry is skipped, the next entry should be returned, rather than an empty entry (this may be complicated by the fact that the current linprocfs_readdir() only returns single entries). However, I'm not very familiar with this area, and there may be a better answer. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message