>>>>> "enh" == Edward Ned Harvey <macenterpr...@nedharvey.com> writes:
enh> How are you managing UID's on the NFS server? All the macs are installed from the same image using asr. And for the most part, there's just one user, except where there isn't, and then I manage uid's by hand. enh> When I did this in the past, I maintained a list of users in enh> AD, and duplicate list of users in OD, so the mac clients enh> could resolve names to UID's via OD. And a third duplicate enh> list in NIS so the linux clients could resolve. It was enh> terrible. Why is that terrible? Is it impossible to automate because of the AD piece? OD/NIS should be dumpable from SQL easily, right? If AD is the unscriptable piece, it just seems kind of sad to throw the whole thing out and standardize on the one piece that's the most convoluted and brittle and least automatable, instead of the other way around. enh> How do you manage your NFS exports? [...] export to the whole enh> subnet yeah, that. r...@1.2.3.0/24 there is a highly stupid bug that would crash mountd for NFSv4 or get incorrect refusal for NFSv3 if the IP was not lookupable in reverse DNS or /etc/hosts. but it may be fixed now because someone from nfs-discuss was unable to reproduce. enh> I would consider it a security risk, if any schmo could take enh> any unused IP address, connect to the server, and claim to be enh> eharvey yeah there is zero security, none at all. I don't really think adding exports restrictions at a finer granularity than subnet would help much. Only Kerberos would help. but most of the security we care about comes from taking snapshots: that's the attack that's relevant here, disgruntled or confused employees deleting everything. This is a robust kind of security, not M&M model. also every desktop has a read-only copy of yesterday's shared filesystem, from another nfs server populated with rsync, pre-mounted, in case of problems with the writeable one. At least it is not crap security like SMB, with five or ten wildly different variants and password formats operating on different ports some with MAC session-binding some without. I admit SMB has some security rather than none, but it's a slow crashy clumsy caveat-laden protocol. You might also look at it this way: if there's going to be a panic/DoS or exploitable buffer overflow security problem, it's far more likely to be in the SMB stack than the NFS stack. (that said, 'mknod <file> b 14 <n>' seems to panic a Solaris NFS server, at least b71.) enh> solved by the launchd.conf edit. Presumably this umask enh> applies, whether you create a folder in Finder, or create a enh> file in MS Word, or save a new text file from TextEdit ... The enh> umask is applied to every file and every folder creation, enh> regardless of which app is doing the creation, right? right. This much works perfectly AFAICT. I suppose if you have a user database and want private user folders, you just make them owned by that user and chmod 700. At least that much works everywhere and survives backup, unlike this complete disaster that is ACL's. I get it, the NFSv3 featureset with no text usernames and no Kerberos unchanged in two decades is not a reasonable answer to modern expectations, and NIS is no longer the unifying directory service it once was now that Mac is a credible client. AD can go fuck itself: buy a windows server and another sysadmin to manage it, or suffer the polluting effect it has on your mind and your entire operation. but, yeah, NFSv3 is not enough. It's zero-security simplicity turns out to be exactly what we need here though, and the Mac client with automounter 10.5 or later, is extremely solid, more than the other Mac filesystems or GlobalSAN.
pgpeQgCjtTO0o.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
