Messages in this thread | | | Date | Fri, 25 Jun 1999 14:37:30 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
On Fri, 25 Jun 1999, Wolfgang Walter wrote:
> Hi, > > how will such a 'directory which can be opened as file' behave compared to > 2.0?
Ummgh... Ask Linus ;-) Frankly, I'm more interested in preventing the horrible clutter that may follow from *any* attempt to play with extended attributes. We already have it with ext2 and that is what I want to clean up. Should we go for directory/symlink stuff or not is a separate story.
> If a simple > > fp = open(<directory>, O_RDONLY) > > opens a default-file in <directory> instead of <directory> itself, then we > have (at least compared to 2.0) a rather subtile change which may implies > some severe security problems.
Umm... Yes, it may be a problem. AFAICS Linus proposed to use O_DIRECTORY to distinguish between those cases, but old applications *will* be a problem.
> At least in 2.0, you may open a directory and use the filehanlde you got later > with fstat, fchown, fchmod. It would be rather bad if this will change.
It would be still available (use O_DIRECTORY), but old binaries may break.
> First you may need this to manipulate directories in a secure way. > Second, most unixes will not have this "directory as file"-feature which means > that a lot of application will not be prepared to handle it correct. > > Even if a directory must be marked with a flag, the security problem is still > there.
It definitely *must* be marked as such. Maybe it's a question of the st_mode we should show for such animals. If they will be marked as S_IFLINK... maybe it will stop the breakage.
> May I misunterstood this thread, in this case forget this mail and pardon me.
Rather confused it with another thread ;-)
> If I didn't, I'm real curious how one will handle this case.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |