On Fri 27 Jan 2012 at 01:54PM, Danek Duvall wrote: > Mike Gerdts wrote: > > > > https://cr.opensolaris.org/action/browse/pkg/dduvall/salvage-special/ > > > > I think bad things happen when running in a zone: > > > > #! /usr/bin/python2.6 > > > > import os > > > > st = os.stat("/dev/null") > > os.mknod("/var/tmp/null", st.st_mode, st.st_dev) > > > > print "OK" > > > > But that gets a traceback: > > > > # /tmp/t > > Traceback (most recent call last): > > File "/tmp/t", line 6, in <module> > > os.mknod("/var/tmp/null", st.st_mode, st.st_dev) > > OSError: [Errno 1] Not owner > > <facepalm> > > I assumed that Claudia's test meant that the fix worked for the particular > situation. I tested in a GZ, though, not an NGZ.
In general, I don't think there will be a problem. At least until we have updater zones or similar. The pkg change-variant that was giving Claudia grief is executed within the context of the global zone. It would be an exceptionally rare situation where a salvage operation running within a zone would cause a problem, as the zone would be able to install device actions in the first place. I can conceive of some odd ways that a device file could come into being, but they represent oddball situations. > In an NGZ, should I simply attempt the mknod, and if it fails on EPERM, let > it go by? I'm not sure how that should work with the testcase, since then > we can't even test in a zone. I think that it is reasonable to just step over it. Zones are not able to do anything useful with devices that aren't in the /dev file system. -- Mike Gerdts Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
