Fwd: Using file type information from POSIX mode

Fwd: Using file type information from POSIX mode

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 681 bytes --]

...resending to the right cifs list...

Folks?

-------- Forwarded Message --------
Subject: Using file type information from POSIX mode
Date: Sat, 9 Nov 2024 10:51:47 +0100
From: Ralph Boehme <slow@samba.org>
To: Steven French <Steven.French@microsoft.com>, Paulo Alcantara 
<palcantara@samba.org>
CC: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>

Steve, Paulo,

it seems kernel client doesn't yet implement using file type information 
from the updated POSIX mode as discussed at SDC:

<https://www.samba.org/~slow/SMB3_POSIX/fscc_posix_extensions.html#posix-file-type-definition>

Any plans? Samba already implements this.

Thanks!
-slow

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Using file type information from POSIX mode

[Pali Rohár]

Hello,

I would like to point out about one comment which I already discussed
with Ralph privately.

Mode as defined in that spec in section "2.1.1 posix mode" is _not_
compatible/same as the UNIX mode used by the Linux, BSD and other UNIX
systems.

The reason is that S_IFREG / S_IFDIR / S_IFLNK / S_IFCHR / S_IFBLK /
S_IFIFO / S_IFSOCK constants does not match with the values defined in
that SMB extension "2.1.1 posix mode".

This SMB extension defines type mask in 32-bit mode via bits 12-14 as:

0 - S_IFREG - regular file
1 - S_IFDIR - directory
2 - S_IFLNK - symlink
3 - S_IFCHR - character device
4 - S_IFBLK - block device
5 - S_IFIFO - FIFO
6 - S_IFSOCK - socket

And UNIX systems including Linux and BSD defines type mask in mode via
bits 12-16 as:

1  - S_IFIFO - FIFO
2  - S_IFCHR - character device
4  - S_IFDIR - directory
6  - S_IFBLK - block device
8  - S_IFREG - regular file
10 - S_IFLNK - symlink
12 - S_IFSOCK - socket

BSD additionally supports also:

14 - S_IFWHT - whiteout

Linux represents whiteout file as char device with both major and minor
numbers set to zero (and so this can be created by non-root user too).

Why where are "holes" in these ranges? This is because other UNIX V7
systems support also other file types. Whole list can be found for
example in extended Ubuntu xenial stat manpage, in section CONFORMING TO
in part "Other systems", which is available online at:
https://manpages.ubuntu.com/manpages/xenial/en/man2/stat.2.html

For completeness those types are:
0  - SCO out-of-service
3  - S_IFMPC - multiplexed character special
5  - S_IFNAM - XENIX named special file
7  - S_IFMPB - multiplexed block special
9  - S_IFCMP / S_IFNWK - VxFS compressed OR network special
11 - S_IFSHAD - Solaris shadow inode for ACL
13 - S_IFDOOR - Solaris door

I just wanted to highlight also for other developers that this SMB POSIX
spec that is not compatible with file type bits used in existing UNIX
systems. So if you are going to implement it, beware of it.

For me it looks very pity if a new spec is saying that is for POSIX
systems but is not compatible with existing UNIX / POSIX systems. But
well, I quite understand that Ralph wanted to do cleanup and remove
something which is not used anymore (like SCO or XENIX stuff; but I'm
not sure about Solaris, this is still used, also there is illumos).

Pali

On Tuesday 12 November 2024 10:30:21 Ralph Boehme wrote:
> ...resending to the right cifs list...
> 
> Folks?
> 
> -------- Forwarded Message --------
> Subject: Using file type information from POSIX mode
> Date: Sat, 9 Nov 2024 10:51:47 +0100
> From: Ralph Boehme <slow@samba.org>
> To: Steven French <Steven.French@microsoft.com>, Paulo Alcantara
> <palcantara@samba.org>
> CC: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>
> 
> Steve, Paulo,
> 
> it seems kernel client doesn't yet implement using file type information
> from the updated POSIX mode as discussed at SDC:
> 
> <https://www.samba.org/~slow/SMB3_POSIX/fscc_posix_extensions.html#posix-file-type-definition>
> 
> Any plans? Samba already implements this.
> 
> Thanks!
> -slow

Re: Using file type information from POSIX mode

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 1143 bytes --]

Hi Pali,

On 11/15/24 3:46 PM, Pali Rohár wrote:
> I would like to point out about one comment which I already discussed
> with Ralph privately.
> 
> Mode as defined in that spec in section "2.1.1 posix mode" is _not_
> compatible/same as the UNIX mode used by the Linux, BSD and other UNIX
> systems.
> 
> The reason is that S_IFREG / S_IFDIR / S_IFLNK / S_IFCHR / S_IFBLK /
> S_IFIFO / S_IFSOCK constants does not match with the values defined in
> that SMB extension "2.1.1 posix mode".

it is not binary compatible and I still don't see a reason why we would 
wanna have that given the ugly smelling kitchen sink it is. We can't 
rely on that historic cruft, we MUST implement a sanitized version of 
this on the wire and then parse it into the format used by the OS we're 
running on.

When implementing the protocol you'll have to implement a fair bit of 
wire parsing anyway, so having something like these function which 
implement the parsing Samba doesn't seem to be a burden:

<https://git.samba.org/?p=samba.git;a=blob;f=libcli/smb/util.c;h=473b479a2abf60cb28ee4374b5d90cb6dda82213;hb=HEAD#l198>

-slow

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Using file type information from POSIX mode

[Pali Rohár]

On Friday 15 November 2024 17:29:49 Ralph Boehme wrote:
> Hi Pali,
> 
> On 11/15/24 3:46 PM, Pali Rohár wrote:
> > I would like to point out about one comment which I already discussed
> > with Ralph privately.
> > 
> > Mode as defined in that spec in section "2.1.1 posix mode" is _not_
> > compatible/same as the UNIX mode used by the Linux, BSD and other UNIX
> > systems.
> > 
> > The reason is that S_IFREG / S_IFDIR / S_IFLNK / S_IFCHR / S_IFBLK /
> > S_IFIFO / S_IFSOCK constants does not match with the values defined in
> > that SMB extension "2.1.1 posix mode".
> 
> it is not binary compatible and I still don't see a reason why we would
> wanna have that given the ugly smelling kitchen sink it is. We can't rely on
> that historic cruft, we MUST implement a sanitized version of this on the
> wire and then parse it into the format used by the OS we're running on.

Well, I just wanted to point out that new SMB format is not compatible.
That is all and to make sure that it is visible for developers who are
going to implement it (as you were asking for Linux cifs.ko
implementation).

One of the reason (except the compatibility) why to use the existing
format is Solaris / illumos support, to allow implementing illumos SMB
client and illumos SMB server and transfer between illumos-illumos all
file types and mode informations.

> When implementing the protocol you'll have to implement a fair bit of wire
> parsing anyway, so having something like these function which implement the
> parsing Samba doesn't seem to be a burden:
> 
> <https://git.samba.org/?p=samba.git;a=blob;f=libcli/smb/util.c;h=473b479a2abf60cb28ee4374b5d90cb6dda82213;hb=HEAD#l198>
> 
> -slow

Of course, but it is important to know about it. That is all.