Garrett D'Amore wrote: > Its been a while since I looked at sudo (brain long since rewired to > pfexec), but IIRC sudo had some kind of support for kerberos. I don't > see any compilation of kerberos in the flags below. Can you provide a > one-or-two sentence description of rationale and impact? (I *suspect* I > know what the reasonable answers are, but I'd like the answers from the > project team directly, and I think it would be good to have the record > in the case log.)
sudo's Kerberos and PAM support are compile time mutually exclusive. The Solaris pam_krb5 module has been tested with sudo and is known to work. Personally I think having to make the choice between PAM and Kerberos at compile time is unfortunate but that is how the upstream code works. Since Kerberos is not (unfortunately in my opinion) not mandatory to use on Solaris PAM is the only sensible choice from that mutually exclusive set. > Second, I notice that the package SUNWsudo is Committed, while > everything else is Uncommitted. This may be ignorance on my part, but > if the entire contents of the package are Uncommitted, then what value > is there in having the package itself be Committed? The fact that sudo willl always be delivered from the SUNWsudo package ? > Third, given that this project lacks Solaris auditing features, I'd > really like to see an explicit statement of this limitation in the > versions of the man pages we ship, perhaps with a recommendation. > Something like: "sudo(1M) does not audit activities. Sites that > require auditing information might consider using pfexec(1)." With my ARC hat on I don't think we shouldn't be vandalising upstream man pages like this in my opinion. This case is to ship sudo as is and the case explictly says so. We don't list all the other things that don't do auditing yet authenticate users, for example webmin authenticates users but doesn't audit, Apache has modules to authenticate unix users and doesn't audit. We didn't change those other components documentation to say they don't audit so I don't think we should ask this project to to that to the sudo ones. > Finally, how will an unconfigured sudo installation behave? (More to The default case isn't actually unconfigured. This case ships the default /etc/sudoers file (in the materials dir). The default sudoers file only allows root to use sudo. > the point, will the "default" installation of sudo create a hole in the > auditing infrastructure, for sites that care to have auditing > information preserved?) Auditing is off by default on Solaris and because of the default sudoers file I don't believe that is an issue. Note that using sudo *will* still cause audit records to be written and the will still have the correct audit id in the records (because sudo doesn't do anything to change that - and shouldn't either). It is still possible to get audit records of what commands were executed and what their arguments were using the ex class. The only real missing part of Solaris audit integration is the equivalent of what pfexec does as application level auditing which is in addition to the syscall auditing. Personally I don't think that is much of a big deal. -- Darren J Moffat
