lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 8 Jun 2020 02:39:50 +0100 From: Jonny Grant <jg@...k.org> To: "Theodore Y. Ts'o" <tytso@....edu> Cc: linux-ext4@...r.kernel.org Subject: Re: /fs/ext4/namei.c ext4_find_dest_de() On 28/05/2020 02:12, Theodore Y. Ts'o wrote: > On Wed, May 27, 2020 at 10:25:43PM +0100, Jonny Grant wrote: >> >> >> How about adding an improved mkdir to POSIX and the Linux kernel? Let's call it mkdir2() >> >> It has one more error, for EISDIR >> >> [EEXIST] >> The named file exists. >> >> [EISDIR] >> Directory with that name exists. > > It's *really* not worth it. You're right. > You seem to really care about this; why don't you just keep your own > version of shellutils which calls stat(1) if you get EEXIST and to > distinguish between these two cases? > > I know the shellutils maintainers has rejected this. But that's OK, > you can have your own copy on your systems. You might want to reflect > that if the shellutils maintainer refused to add the stat(1) on the > error path, what makes you think they will accept a change to use a > non-standard mkdir2() system call? You're right, it's unlikely. > If you want to try to convince Austin Common Standards Revision Group > that it's worth it to mandate a whole new system call *just* for a new > error code, you're welcome to try. I suspect you will not get a good > reception, and even if you did, Linux VFS maintainer may well very > well deride the proposal as silly, and refuse to follow the lead of > the Austin group. In fact, Al Viro is very likely not to be as > politic as I have been. (It's likely the response would have included > things like "idiotic idea" and "stupid".) > >> I'm tempted to suggest this new function mkdir2() returns 0 on success, or >> an error number directly number. That would do away with 'errno' for this as >> well. > > This is not going to get a good reception from either Al or the Austin > Group, I predict. If you really have strong ideas of what you think > an OS and its interfaces should look like, perhaps you should just > design your own OS from scratch. Yes, I agree, no one would want to change anything. I recall other APIs like pthread_setname_np return 0 on success, and the error code directly, so there is some trend in that direction. That's part of POSIX.1 Hmm designing an OS, could be fun as a hobby, but wouldn't be big and professional like linux is on x86 x64 these days. I'd probably seek feedback on things people like/dislike in POSIX, as any OS would resemble it somewhat anyway, at least due to practical reasons compiling common tools. It would end up with a POSIX wrapper, on top of any APIs I designed, and then there would be no reason to use my APIs anyway. It's more fun to contribute to something with global appeal than a hobby project. Regards, Jonny
Powered by blists - more mailing lists