linux-ext4 - Re: /fs/ext4/namei.c ext4_find_dest

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fea0b424-cdb4-b6f8-ec0a-3aae8d66233e@jguk.org>
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