User Details
- User Since
- Jan 13 2015, 10:58 PM (517 w, 3 d)
Wed, Dec 11
Mon, Dec 9
Sun, Dec 8
Sat, Dec 7
Oh, and I think just copying fid_data would fix cd9660
as well, for those who don't like __packed.
Btw, I replaced "sizeof(struct fid)" with MAXFIDSZ in the _Static_assert()
and it passed (at least for amd64).
Good catch w.r.t. the _Static_assert(). It does need to be fixed,
even if these changes don't go in.
I'll leave it someone familiar with tmpfs to decide if having
tn_gen wrap around to zero is a real concern.
Just fyi, whenever the "struct fid" changes, the file handles
change. As such, an upgrade of the NFS server requires that
all clients be unmounted/remounted.
Fri, Dec 6
Added upper bound check for port# as suggested
by delphi@.
Looks fine to me.
Btw, ext2fs and tarfs both are broken w.r.t. *fid size.
Thu, Dec 5
Tue, Dec 3
As far as I know, the NFS server code does not look inside the fid structure.
Fri, Nov 29
Mon, Nov 25
Sun, Nov 24
Oct 24 2024
Oct 21 2024
Looks fine to me. You might ask manpages for a review as well.
Oct 19 2024
Oct 16 2024
Looks ok to me.
Oct 14 2024
This version looks fine to me.
Oct 13 2024
I'll click Accept, although I do not think it makes the code
clearer.
Just make it clear in the commit message that there are
no semantics change/bugfix done by this commit.
Oct 12 2024
I did test the above patch along with a "hack" that set cr_groups = NULL,
so any access would cause a crash.
The only one I got was from a totally bogus line in nfsd_excred(0 which
looks like: nd->nd_cred->cr_gid = credanon->cr_gid;
just before crsetgroups(), so it is harmless noise (left over from code meant
to work for BSDen that had a separate cr_gid.)
Oct 11 2024
Oct 9 2024
Looks fine to me, since ngroups_max can never
be set < NGROUPS_MAX.
Oct 8 2024
Oops, when I said grouplist() above, I meant groupmember(), which I
think is the only function that checks to see if a credential has a group
that matches the group ownership of the file (or the ACE in the ACL for
the file).
Yuck! I never noticed this in the man page (I'm not going to look and
see who the author was, it might have been me long ago;-).
Oct 7 2024
Yes. The historical background wass just FYI for whoever was reading this
and wondering why the code would check for a duplicate.
I agree with you that the duplicate is unlikely to still exist in passwd/group databases
used by FreeBSD, so removing the code seems reasonable and does simplify the
code slightly.
Remember this code is setting up exports. The "credentials" are created
from the exports in the kernel. It has nothing to do with setuid()/setgid()
etc. for processes.
Oct 4 2024
You claim there are bugs that result in no groups
(cr_ngroups == 0), but you do not show a specific
test case that finds this or describe exactly how it
happens.
--> If there is such a case (I am not aware of one),
we should try to isolate/fix that such that there is always at least one group in the credentials.
(There is always at least one group in the credentials
that come on on-the-wire, since there is a separate gid
in the Sun RPC AUTH_UNIX authenticator from the
list of additional groups.)
I will look at the patches later, but just in case you are not aware of
why a lot of this weirdness exists in the code...
Sep 30 2024
Sep 29 2024
Sep 28 2024
Sep 27 2024
Sep 15 2024
Sep 10 2024
Just fyi, I have created a Pull Request for this on OpenZFS,
so please review it over there.
Sep 6 2024
Aug 31 2024
Aug 27 2024
Aug 21 2024
Aug 17 2024
Aug 8 2024
Jul 28 2024
Jul 23 2024
Jul 22 2024
Jul 21 2024
Jul 13 2024
Jul 11 2024
Jul 9 2024
Jul 7 2024
No problem Ed. Hope you enjoyed your vacation.
The code changes are pretty straightforward. I left
them in the style consistent with the rest of the code.
(Using "int"s instead of "bool"s for example.)