Roland Mainz writes:
> But for now I really wish we can do the putback for update1 _ASAP_ since
> we're now many many months late because we tried to fix any bug+RFE
> filed and prepare a "hyper-perfect" putback (which backfired badly, we
> even missed the OpenSolaris 2008.11 release(!!) which was _extremly_ bad
> and caused lots of "collateral damage" elsewhere).
Yep; understood. Thanks for the detailed roadmap.
> > > > usr/src/Makefile.ast
[...]
> > None of that should really be a barrier.
>
> Well, I disagree a bit since IMO it only adds some complexity in the
> Makefiles without having a benefit from it (e.g. OS/Net doen't support
> partial download+compilation or something like that).
Actually, it does (or at least _did_). That's what all those req.flg
and inc.flg files now littering the gate are about, and Teamware
supported bringing over subtrees, using those files to determine which
parts were needed for any particular subtree. But since Mercurial (as
we're currently using it) doesn't support this, the support there is
mostly rotting on the vine.
It's still possible to cd into subdirectories within a complete
workspace and build individual items, though. You may have to find
some of the larger dependencies and build them first (particularly if
your build machine isn't up-to-date or if you depend on private
libraries), but it otherwise works just fine.
> We can try to
> remove the usage of private headers from the "shcomp" and "ksh" frontend
> sources (which would eliminate the cross-tree include linking in this
> case).
That'd probably also reduce confusion, though I would assume that's
"not this project."
> > I guess I don't care too
> > much about this, and you can certainly plow on without changing it,
> > but I do think can make the source slightly harder to manage over the
> > longer term, because you may end up with a small forest of confusing
> > "-I" options.
>
> Well the forest is unlikely to grow in this case since we have the only
> two consumers ( { ksh, shcomp } ) of the private headers in the tree.
OK; I give.
> > Notably, when I added CDDL in the first place, I wasn't
> > allowed to change any of the dates.)
>
> Why ?
I was told explicitly by the lawyers that I must not change copyright
dates.
I'm not a lawyer, but my lay understanding of the issue was that the
boilerplate comments for licensing aren't considered the "expression
of an idea" in terms of the code itself (copyrights cover
"expression"), so if you change the copyright date without changing
the expressed idea in any way, then you're doing at least two bad
things:
- you're explicitly cheating on the term of a copyright; you can't
just keep changing the date, and expect it to hold up in court
(well, unless you're a *really* big company with a rodent for a
mascot).
- you might be diluting the significance of your claim of copyright
on any of your other materials -- the same as stamping "secret" on
everything indiscriminately makes nothing a secret.
Over the years, we've had different lawyers tell us slightly different
stories about this. For some, I think just about any SCCS delta was a
copyrightable change, even if the only thing that changed was the SID
itself. For others, the binary produced itself had to change. And
we've had a few opinions somewhere in between. Here's a reference to
the (somewhat ambiguous) current policy (at least as far as I know):
http://www.opensolaris.org/os/project/muskoka/on_dev/golden_rules.txt
My current understanding of this is that copyright dates are updated
only if there are substantive changes: not mere changes to licensing
or to comments (or the recursive "I changed the copyright date because
I changed the copyright" argument), but to the remainder of the text
in the file.
Because of all that, I'm careful about when and where I change a
copyright.
> > Wow; that's a strange one. OK. It'd be nice to have either a comment
> > here or a CR filed so that future generations won't find this odd flag
>
> Already fixed - I centralised the CFLAGS/CFLAGS64 bits in
> usr/src/Makefile.ast and added a comment there. The bug report will
> follow after the integration that we can simply say "... remove that
> flag in OS/Net and watch your compiler die in a horrible way...".
Thanks; that helps.
> > and either (a) rip it out because they don't understand what it does
> > or (b) go all cargo-cult on us and copy it into other makefiles.
>
> "cargo-cult"... ROTFL... :-) :-)
You'd be surprised. Cut-n-paste development strikes in a number of
ways, and really obscure makefiles are often one of the results.
> > > > usr/src/cmd/ksh/Makefile
[...]
> > Have you discussed the combination with any of the RBAC folks? The
> > idea seems (to me) to confuse the separate notions of "user" and
> > "role."
> >
> > Existing restricted shells typically aren't used for scripts --
>
> Uhm... that's not true. If you look at the demo section you'll see some
> stuff like the IRC bot which switch to restriced mode to process
> user-input (to prevent any possibilties that the user input can be used
> to compromise the host machine of this internet-facing application).
I said "typically." I know it's obviously technically possible to use
a restricted shell for a script.
I think it's odd, and I've never seen a real application of it outside
of demos.
> >From my experience you sometimes have tasks like _manually_ starting a
> backup by employing students (or in my case it was part of my "Civilian
> Service" (see http://en.wikipedia.org/wiki/Zivildienst) to go once a
> week to a Himalaya-class system and insert tapes, run backup (and wait
> the 30-90mins in the room until the backup is done), remove tapes, store
> them in the next room). And in such cases they should only be allowed to
> execute _exactly_ the commands they are supposed to do and not use the
> machine to download, compile and run Quake2.
Yep.
So, they log in and type either "su backuprole /sbin/backup" or
perhaps "pfexec /sbin/backup" or some such. No special "restricted
profile" shell is needed; the existing restricted shell works fine.
> That's why I think a "pfrksh" is a good idea (I disagree a bit about the
> abuse of students for that but that seems to be the way this world
> works... :-) ).
It may be a good idea. I don't think I understand it, though, or how
it fits into the overall system, or when you'd use it versus any of
the other existing mechanisms, or (perhaps more importantly) if there
are cases when you might _not_ want to use it.
That's why I suggested discussing with at least the RBAC folks; you'll
find them hanging out on security-discuss at opensolaris.org.
> > In any event, that CR you're citing is in "Dispatched" ("nobody
> > cares") state; it'd be good to have someone add an evaluation and get
> > it into a state where you can integrate. (Yes, I know that's
> > something you can't control directly ...)
>
> Well, I was temped to request sponsorship for this RFE but it's for the
> original Bourne shell codebase and I have sworn myself not to try to fix
> this thing - it would be a sisiphos-type of work (that starts with all
> multibyte handing bugs in this code, crashers, problems with memory
> allocations, signal handling issues and other stuff).
OK.
> In the meantime I didn a small experiment which quickly grew out of
> control - or better "out of linecount": Right now it's around 59 lines
> and I have problems bending my mind to understand how it works. So the
> correct answer is more likely: It is possible but may cause brain-damage
> to the author. I really prefer my current version since I can at least
> understand it (and explain it to anyone who needs an explanation) by
> looking a few seconds on it.
OK; I give on that as well.
> > > > usr/src/cmd/ksh/Makefile.com
[...]
> > But why is it needed both in the top level makefile and in this
> > makefile.com? Are both this makefile and the subdirectory makefiles
> > producing the same targets? If so, why? Doesn't that just mean that
> > we do the same work twice?
>
> No, they are seperate targets because we use "isaexec" to select the
> 32bit/64bit versions (and in the future machine-optimized versions may
> appear since we now have proof on x86 that we get a nice performance win
> when we compile some of the libs with more advanched options which will
> not work on older CPUs).
Right. That explains the copy that's in Makefile.com, because that's
included by the per-architecture subdirectories. It does not seem to
explain the top level Makefile targets.
> > > > usr/src/lib/libsum/THIRDPARTYLICENSE
> > > >
> > > > Not an issue for my review, but someone should make sure that this
> > > > new license gets packaged and delivered properly.
> > >
> > > Uhm... what do you mean with that ?
> >
> > The license bits have to show up in the 'copyright' files for the
> > packages produced. I haven't checked whether that's done correctly
> > here -- if it is, then no problem. I'm just warning that it's an
> > issue to check (and outside of makefiles).
>
> How can I check that ?
It needs to be listed in the LICENSEFILES macro in the Makefile for
the package that contains this library. If that's SUNWastdev, then
it's usr/src/pkgdefs/SUNWastdev/Makefile.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
