Yes, I use >SFS explicitly and the directory is not currently accessed. I rely on >SFS to write to the sfs file space without it being accessed.
The diag d4 is done just before the pipe command. It’s rather dynamic because the userid is running a web server application that requires authentication. The application uses diag d4 to set the altuser while that bit is code runs then diag d4 again on exit to reset altuser. I specify the file name, type and fully qualified sfs directory on the >SFS stage. It sounds like the driver is not getting a new work unit. I could call the CSL to get a new one after diag D4, then specify default on the stage and delete work unit after the pipe completes…. On Wed, Dec 13, 2023 at 23:26 Rob van der Heij <rvdh...@gmail.com> wrote: > On Thu, 14 Dec 2023 at 05:40, Donald Russell <russell....@gmail.com> > wrote: > > > > > Thanks Rob, > > Since >SFS uses a private work unit by default, doesn’t that mean it > gets a > > new work unit before connecting to the sfs server? Diag d4 is done before > > the pipe command, so I’m expecting the new connection to appear to > initiate > > from the altuser id. > > > > And that means you specify the file such that the nose driver knows to use > >sfs and not go through the mini disk simulation on accessed SFS > directories... > > > > > Am I misunderstanding what PIPE AHELP >SFS is telling me? What > > does”PRIVATE” mean in this context? > > > > It means >sfs allocates a work unit specifically for that file, so nothing > else in the virtual machine observes the effect until the stage ends. > > I know CMS caches persistent IUCV connections to the SFS server. I don't > recall playing with D4 like this. I don't know whether CMS keeps track of > the identity while the IUCV connection was established, and knows to expire > that when things change. > You normally do the D4 very early in the life of the virtual machine, so > you can reason about the possible leakage of data between the two > identities. I know from experience that once you try to aggregate rights > from different identities, things get very complicated. You could for > example link to a disk as user A and then identify as B and link another > disk. When you then run an application associated with A, you do that with > the privilege of user B. > > Rob >
