You didn't create that. Well, you did, but you can't delete it now.

Recently, I ran into a very strange situation where a process that had been working flawlessly just stopped dead. The specifics of the case had to do with creating a new file in the IFS and then not being able to delete it or even read it. Everything had been working smoothly for weeks but then just stopped. Finding out why was an absolute nightmare because every assumption I made simply proved the old adage about “assume.”

The Setup

This was a simple situation. I have a third-party vendor that, during a proof-of-concept phase, wants some data in a CSV file. Simple enough; I create a lovely SQL view over the data in question, execute CPYTOIMPF, map a drive to the folder, copy the file, and drop it into an email. This worked fine until 20 minutes before a critical conference call when I wanted to get something out based on the morning's most recent emails. And the problem wasn't that I couldn't create the file; I could create it just fine. The problem was that I could no longer copy it to my PC to send it in an email!

And then I couldn't delete it. I couldn't delete the file I had just created.

What was going on here?

IFS Authorities and Guest Profiles

As I alluded to in my introduction, this was really a perfect storm of errors that all combined into an entirely crazy situation. Let's start with some facts:

1. I was using a mapped drive to an IFS directory.
2. The IFS directory had *RWX access granted to *PUBLIC.
3. Any files created in that directory would also have *PUBLIC *RWX.

Operating with this understanding, I had believed that any file created in the folder would be accessible by not only me (since I would be the owner) but also everybody else, because the file would inherit the access from the parent directory. Well, as it turns out, I was wrong on both counts.

First, and foremost, I was not logging on to the folder with my user profile. Initially, I mapped drives with that profile, but at some point, those drives got disconnected, and then when I tried to access them, Windows tried to attach to them using my Windows user ID and password. This should have caused the system to prompt for my user ID and password, but it did not, so I went blithely along my way believing I was logged in with my previous credentials.

That was a very bad assumption. Sometime back in the distant past, I had configured my system with a guest profile. What this means is that I can log on to mapped drives on my system without a user ID and profile. This is a rather large potential security hole in any production environment. It is in effect a second *PUBLIC for the IFS. You can see whether you have a guest profile configured either by using System i Navigator (whichever incarnation you currently have) and go to the NetServer properties:

Figure 1: NetServer properties in IBM i Navigator show a guest user ID in the Security tab.

Notice how clever I was creating a user profile named NONE? What this means is that if you attempt to log into a shared folder on my machine but you don't have a valid user profile, you will be granted access with the user profile NONE. And while this can be a great time-saver for a number of reasons, it's clearly a serious back door. Sometimes I really hate when I'm clever.

Just as a quick aside, there's also a little-known green-screen utility that you can use to get at that value:

Figure 2: Use the CHGNSVA command from QUSRTOOL.

The Final Piece of the Puzzle

So OK, I was logging on as NONE. But even so, why couldn't I access the files I had just created? While it's not exactly intuitive, I've got a reasonable understanding of how IFS authorities work. In simplest terms, when you create a file in a directory, the file initially receives the same authorities as the parent directory. It's not quite that simple as I'll explain in a moment, but it's a good rule of thumb. Yet I wasn't able to access the file I had just created. What was the problem? I'd been doing this before with my own program that was creating files directly using IFS APIs; why would that work but not CPYTOIMPF?

That turns out to be a specific "feature" in CPYTOIMPF. It's actually spelled out clearly in IBM's page on IFS Authority Considerations, but even so, it's completely non-intuitive. When you use CPYTOIMPF (or CPYTOSTMF), the resulting stream file has no public authority (or group authority, but that's a complication I don't even want to address today). So since I was signed on as me, when I created the file I got authority. But remember that I was mapped to the folder as user profile NONE, and since the file had no *PUBLIC authority, user NONE couldn't get at it.

This was definitely not what I was expecting. But after reading the web page above and doing a little experimentation, I ended up with a working approach. The closest thing I've found to the expected behavior is to use the keyword STMFAUT(*INDIR) on the CPYTOIMPF command. This keyword acts the same way as creating the file with the IFS APIs, granting authorities to the new object based on the directory in which it was created. While there are other options for that keyword, this is the one I'm most comfortable with and will continue to use.

One Last Complication

It is almost impossible for me to describe the issue here. IBM does as good a job as can be done on the page I previously mentioned above, but it's still confusing. In as simple terms as possible, the problem is that IFS initial authority is a bit more nuanced than it can seem at first. The user who creates a file has the same authority to that file as the owner of the parent directory has to that directory. So if you create a directory and then revoke the owner's authority, then users creating items in that directory will not have authority to those files.

You in effect have a write-only folder. While you may need that one day, my guess is that in virtually every project you have today you don't want that to happen. So to save yourself potential headaches, please be sure that the owner of a directory always has access to that directory.

A Little Understanding

OK, that's it for IFS directories and authorities. The IFS is a wonderful tool, especially as we continue to expand the inter-connectivity of our beloved midrange platform. We just need to understand how to use it.