Bug 86596 - 2.0b1 release is missing the synth auxilary
2.0b1 release is missing the synth auxilary
Status: CLOSED WONTFIX
Product: eCos
Classification: Retired
Component: Release Engineering (Show other bugs)
2.0 beta 1
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dallaway
John Dallaway
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-26 03:32 EST by Andrew Lunn
Modified: 2007-04-18 12:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-20 12:22:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Lunn 2003-03-26 03:32:15 EST
The 2.0b1 release does not appear to contain the linux synth auxilary code. It
should probably live under tools/libexec.
Comment 1 Bart Veer 2003-03-26 09:22:00 EST
All the sources for the I/O auxiliary are included in the release, e.g. in
packages/hal/synth/arch/v2_0b1/host, but currently we do not provide prebuilt
binaries.The main problem is that some of the binaries, e.g. rawether, need
to be installed suid root. That does not fit in with the tarball distribution
mechanism which we are still using for 2.0. Instead in due course we'll need
to switch to e.g. RPM's, either instead of or in addition to tarballs.That was
not possible in the 2.0 time frame, but hopefully this area can be sorted out
for 2.1.
Comment 2 Jonathan Larmour 2003-03-26 10:11:46 EST
RPMs aren't particularly a solution to this... we could fix this just as well
using tarballs. The only "solution" RPMs have is that they _require_ people to
be root to install, which tarballs don't. This isn't an advantage!
Comment 3 Andrew Lunn 2003-03-27 04:41:37 EST
tar should be able to preserve the suid if its unpacked as root. 

I don't see this being a big issue. Its clearly documented that it has to run as
root and you explain the risks. What happens if its not run as root? Is the
error message clear?

I think the other parts of the auxilary are sufficiently useful that they should
be in 2.0 in binary for if possible.    
Comment 4 Bart Veer 2003-03-27 08:00:51 EST
The key point is "if the tarball is unpacked as root". A requirement, set by
the release manager, is that tarballs can be unpacked by ordinary users in e.g.
their home directories. That allows students and the like to install eCos
without having to involve their sysadmins. I am not entirely convinced by this
policy. but never the less it is a restriction we have to abide by for now.

So we could ship the binaries in theory (although that involves changing the
release scripts which John may not be happy with at this stage), but we cannot
assume that the unpacked binaries are owned by root and suid. Hence they may
not work. It might be sufficient to detect insufficient privileges and give
appropriate warnings, but right now that doesn't happen and would require yet
more changes.

Once you start installing as root, you should use proper package management
and allow people to easily upgrade and uninstall. Hence RPM's rather than
tarballs.
Comment 5 Alex Schuilenburg 2003-06-20 12:22:55 EDT
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=86596

Note You need to log in before you can comment on or make changes to this bug.