Suricata

QianKai Lin wrote:

Description¶

Some new enumerations were defined in the NFSv4.1 RFC such as Exclusive4 in createmode — could you implement them?

Sorry, it's Exclusive4_1 not Exclusive4

Can you include the complete list of what is missing here?

Victor Julien wrote in #note-3:

Can you include the complete list of what is missing here?

createmode4¶

/*
 * Various definitions for OPEN
 */
enum createmode4 {
        UNCHECKED4      = 0,
        GUARDED4        = 1,
        /* Deprecated in NFSv4.1. */
        EXCLUSIVE4      = 2,
        /*
         * New to NFSv4.1. If session is persistent,
         * GUARDED4 MUST be used.  Otherwise, use
         * EXCLUSIVE4_1 instead of EXCLUSIVE4.
         */
        EXCLUSIVE4_1    = 3
};

Do you have a pcap for testing?

Thanks for adding the NFS 4.1 pcap. I'm looking at this and have made some changes. Can you provide an example of the malformed data? I'm trying to determine if the changes I've made are correct.

Jeff Lucovsky wrote in #note-10:

Thanks for adding the NFS 4.1 pcap. I'm looking at this and have made some changes. Can you provide an example of the malformed data? I'm trying to determine if the changes I've made are correct.

I have only one unit test, you can try it.

    #[test]
    fn test_nfs4_request_open_exclusive4_1() {
        #[rustfmt::skip]
        let buf: &[u8] = &[
            0x00, 0x00, 0x00, 0x12, /*opcode*/
            0x00, 0x00, 0x00, 0x00, /*_seq_id*/
            0x00, 0x00, 0x00, 0x02, /*_share_access*/
            0x00, 0x00, 0x00, 0x00, /*_share_deny*/
            0x91, 0xe9, 0xf1, 0x68, 0x59, 0x18, 0x8d, 0xec, /*_client_id*/
        // OWNER
            0x00, 0x00, 0x00, 0x18, /*owner_len*/
            0x6f, 0x70, 0x65, 0x6e, 0x20, 0x69, 0x64, 0x3a,
            0x00, 0x00, 0x00, 0x74, 0x00, 0x00, 0x00, 0x00,
            0x00, 0x01, 0x7a, 0xa1, 0x15, 0xa6, 0x3d, 0xaa,
        // OPEN
            0x00, 0x00, 0x00, 0x01, /*open_type: OPEN4_CREATE*/
            0x00, 0x00, 0x00, 0x03, /*create_mode: UNCHECKED4*/
            0x9a, 0xf1, 0xf6, 0x18, 0xdc, 0xe2, 0x00, 0x00, /*verifier*/
            0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,
            0x00, 0x00, 0x00, 0x08,  /*attr_mask*/
            0x00, 0x00, 0x01, 0xa4, 0x00, 0x00, 0x00, 0x12, /*_reco_attr*/
        // CLAIM_TYPE
            0x00, 0x00, 0x00, 0x00, /*_claim_type: CLAIM_NULL*/
            0x0, 0x0, 0x0, 0x8, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x70, 0x6e, 0x67, /*filename*/
        ];

        let (rem, request) = nfs4_req_open(&buf[4..]).unwrap();
        assert!(rem.is_empty());
        match request {
            Nfs4RequestContent::Open(req_open) => {
                assert_eq!(req_open.open_type, 1);
                assert_eq!(
                    req_open.filename,
                    [0x74, 0x65, 0x73, 0x74, 0x2e, 0x70, 0x6e, 0x67]
                );
            }
            _ => {
                panic!("Failure, {:?}", request);
            }
        }
    }

Hi guys, I think you should also implement OPEN_DOWNGRADE operation.
Please refer to https://datatracker.ietf.org/doc/html/rfc7530#page-260

QianKai Lin wrote in #note-13:

Hi guys, I think you should also implement OPEN_DOWNGRADE operation.
Please refer to https://datatracker.ietf.org/doc/html/rfc7530#page-260

Please create a separate ticket for this. Any additional information you can provide in the ticket, including a pcap, would be helpful.