> Just saying "you should not do that" will not prevent any user to do it > anyway.
That is not what I was saying. Most of us strive to write utilities in the most efficient way. We don't use system features in programs that don't require it. We write a sparing but sufficient userland. That's why I mean it is pointless to hold vnodes in programs which don't need to do so. > So I am unsure if the problem is really "abusing kernel resources". It > is more "you can't use naively unveil(2) on user provided list" bcause > your program has more chance to quit unexpectly (so eventually something > to clarify in unveil(2) man page ?) Absolutely it is abuse of kernel resources. Let me provide an example with cat. cat opens each argv[] one after the other, and shows the output. It only has 1 such fd open at a time. As a result only one vnode is in use at a time, in the kernel the footprint is minimal. If cat was modified to unveil the first 64 or 128 arguments, that would be wasteful. Shall I write a diff so that cat holds up to 64 or 128 fd's open and does 'lazy-close'? It is a contrived example. But the lesson I'm trying to provide is that unveil should be used when it participates in the creation of a security boundary, otherwise it should not be used at all. My example doesn't actually solve a security issue in in cat, and there isn't such an issue in file either.
