Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #917

Re: Need advice about fixing PROC mount failures in a DIY Linux container

Cross-posted to 4 groups.

Show all headers | View raw

On Sat, 07 Jan 2023 01:27:28 +0000, Lew Pitcher wrote:

> Hi, all
> 
> I've come late to the party, and have just started learning
> about the ins and outs of Linux containers. To get a better
> understanding of the subject, I decided to learn about the
> underlying technologies by building my own container software.
> 
> I've modelled my DIY container on Brian Swetland's mkbox
> container[1], and have a demonstration program that works
> on my development system (a 64bit AMD Ryzen 5 3400G with
> Radeon Vega Graphics, running Slackware Linux 14.2 with
> the 4.4.301 kernel and all available patches applied).
> [1] https://github.com/swetland/mkbox
> 
> 
> However, when I run either Brian's mkbox or my demo program
> on my "production" system (another 64bit AMD Ryzen 5 3400G
> with Radeon Vega Graphics, running Slackware Linux 14.2 with
> the 4.4.301 kernel and all available patches applied), the
> container breaks while trying to mount the proc filesystem
> to the new (isolated) root fs.
> 
> Specifically, I get an "Operation not permitted" error when
> I try to
>   mount("proc","proc","proc",MS_REC,NULL)
> /but/ ONLY ON THIS ONE SYSTEM.
> 
> This failure affects both my DIY container and Brian's mkbox
> container.
> 
> With my DIY container, I've checked the capabilities given
> to the container process, and they are identical and complete
> on both systems. On both systems, I run the container process
> (mine and Brian's) from the same unprivileged UID/GID.
> 
> I have to conclude that there's a difference in the two
> environments that causes this problem, but I don't know what
> that difference is. Both systems use the type CPU, the
> same amount of memory, the same 64-bit addressing mode,
> the same kernel, and the same distribution (with the same
> essential utilities).
> 
> There /are/ differences in the two systems:
> pn the development system, my user is a member of a
> number of groups that it is not a member of on the 
> "production" system. I run a root pulseaudio (I have my
> reasons) on the development system that I do not on
> the "production" system. Et cetera.
> 
> Can anyone suggest an environmental factor or set of
> factors that might cause this behaviour?
> 
[snip]


Well, I can answer my own question, now. But the answer
leads to more questions.

The reason I get "Operation not permitted" on the
container /proc mount on my "production" system is that
I also run an nfs server on my "production" system (and
do not run one on my development system), and is nfs
server maintains two mountpoints within the /proc
filesystem.

Apparently, the attempt to mount /proc within my container
was blocked by the existance of these two mount points
(/proc/fs/nfs and /proc/fs/nfsd), as when I shut down my
rpc and nfs servers, and umounted these two mounts, I could
successfully run my demo container.

/Now/ the question is: how do I get my container /proc mount
to ignore or bypass these two nfsd mounts?


-- 
Lew Pitcher
"In Skills, We Trust"

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Need advice about fixing PROC mount failures in a DIY Linux container Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-01-07 01:27 +0000
  Re: Need advice about fixing PROC mount failures in a DIY Linux container Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-01-07 02:12 +0000
    Re: Need advice about fixing PROC mount failures in a DIY Linux container Jasen Betts <usenet@revmaps.no-ip.org> - 2023-01-07 07:06 +0000
    Re: Need advice about fixing PROC mount failures in a DIY Linux container John-Paul Stewart <jpstewart@personalprojects.net> - 2023-01-07 11:41 -0500
    Re: Need advice about fixing PROC mount failures in a DIY Linux container Rainer Weikusat <rweikusat@talktalk.net> - 2023-01-09 19:27 +0000

csiph-web