Russ Allbery <[EMAIL PROTECTED]> writes:
> Can you run something that uses libpam-openafs-session inside strace and
> see what happens at the system call level when it attempts to determine
> whether AFS is running? It should be trying to open
> /proc/fs/openafs/afs_ioctl and read and write data to it. Either that's
> failing or it's not liking what it's getting in return.
I straced sudo and found this in the output:
open("/proc/fs/openafs/afs_ioctl", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/proc/fs/nnpfs/afs_ioctl", O_RDWR) = -1 ENOENT (No such file or directory)
I looked in /proc, and found that /proc/fs doesn't exist within the
vservers. After digging around, I found that I could make
/proc/fs/openafs/afs_ioctl visible within the vservers with some
setattr commands on the host system:
# setattr --~hide /proc/fs/
# setattr --~hide /proc/fs/openafs
# setattr --~hide /proc/fs/openafs/afs_ioctl
And now I get a PAG with a token when logging into a vserver on that
host. Problem solved?
Can you think of any reason why it would be a problem for the host's
/proc/fs/openafs/afs_ioctl to be available to all of the vservers?
Any security implications? Could one vserver do something to the host
or to another vserver by having access to this?
If so, could there be some other way for the pam module to detect the
presence of afs, or some way to override what the pam module currently
does to detect afs?
-kevin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
