headers
Alan Barrett | 2 Mar 2007 13:29
Gravatar

reverting MAKEDEV.subr

Splitting MAKEDEV.subr from MAKEDEV has caused much more trouble than I
anticipated.  I now suggest:

1. move all the function definitions back into MAKEDEV;

2. delete MAKEDEV.subr;

3. Add a way to use MAKEDEV as a function library via ". MAKEDEV".
   This can be implemented by adding a line like

      [ -n "${MAKEDEV_AS_LIBRARY}" ] && return

   after the function definitions buf before doing any real work.

4. Let MAKEDEV.local use "MAKEDEV_AS_LIBRARY=1 . MAKEDEV" to get the
   function definitions directly from MAKEDEV without MAKEDEV.subr
   existing at all.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Quentin Garnier | 4 Mar 2007 19:41

Removal of SA vs. icky libc ABI breakage

Hi,

Following the removal of SA and its syscalls, there have been
discussions on how to use older releases with a post-newlock2 kernel.

The theory is that you just have to drop in a new libpthread and libc in
the file-system and everything should work as before.

Well, that's not true, unfortunately, as Lubomir Sedlacik reported
privately.  It appears a couple of symbols from libc, found in all the
3.x releases and in the upcoming 4.0 release, were removed in October.

Those symbols are hmac_sha1 and hmac_md5, and while it is true that
nothing but libcrypt should have ever used them, it means that older
libcrypt (as found in 3.x) fail to link with -current's libc.

I don't what the best way to solve that is...  If we really want to
solve it, that is, but such breakage of the ABI is really, really
unfortunate.

Additionally, I wonder if libcrypt's minor should be bumped.  I'm not
100% sure about that, as the hmac_sha1/md5 symbols that are now there
are supposed to be internal.  The thing is, since you have to drop in
libpthread, libc and libcrypt in an older system to make it work
flawlessly with a new kernel (only the .so's, of course), it looks a
bit less risky if you don't have to actually replace any file, but
just the symlinks.

To sum up:
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Laight | 4 Mar 2007 19:47
Picon

Re: Removal of SA vs. icky libc ABI breakage

On Sun, Mar 04, 2007 at 07:41:42PM +0100, Quentin Garnier wrote:
> Hi,
> 
> Following the removal of SA and its syscalls, there have been
> discussions on how to use older releases with a post-newlock2 kernel.
> 
> The theory is that you just have to drop in a new libpthread and libc in
> the file-system and everything should work as before.

I think that it may only be necessary to create a small .so containing
the new syscall stubs.  Then only the new libpthread would be needed.

Maybe ld.so.conf could get the library loaded, alternatively it could
be built with a .SONAME matching that of libpthread, with a .NEEDED
entry to pull in the new libpthread itself.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 4 comments |
headers
Quentin Garnier | 4 Mar 2007 20:58

Re: Removal of SA vs. icky libc ABI breakage

On Sun, Mar 04, 2007 at 06:47:58PM +0000, David Laight wrote:
> On Sun, Mar 04, 2007 at 07:41:42PM +0100, Quentin Garnier wrote:
> > Hi,
> > 
> > Following the removal of SA and its syscalls, there have been
> > discussions on how to use older releases with a post-newlock2 kernel.
> > 
> > The theory is that you just have to drop in a new libpthread and libc in
> > the file-system and everything should work as before.
> 
> I think that it may only be necessary to create a small .so containing
> the new syscall stubs.  Then only the new libpthread would be needed.
> 
> Maybe ld.so.conf could get the library loaded, alternatively it could
> be built with a .SONAME matching that of libpthread, with a .NEEDED
> entry to pull in the new libpthread itself.

What do you propose to distribute and install that .so?  I agree that
just that is needed, but it's about as hard to install.

--

-- 
Quentin Garnier - cube <at> cubidou.net - cube <at> NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
Permalink | Reply | 0 comments |
headers
Lubomir Sedlacik | 5 Mar 2007 02:46

Re: Removal of SA vs. icky libc ABI breakage

On Sun, Mar 04, 2007 at 06:47:58PM +0000, David Laight wrote:
> I think that it may only be necessary to create a small .so containing
> the new syscall stubs.  Then only the new libpthread would be needed.
> 
> Maybe ld.so.conf could get the library loaded, alternatively it could
> be built with a .SONAME matching that of libpthread, with a .NEEDED
> entry to pull in the new libpthread itself.

both ways work, i just tested.  here's what i did.

1)

 - linked the proxy lib:

 [/opt/obj/lib/libc]> /opt/tools/bin/i386--netbsdelf-ar cq
    libpthread_lwp_stubs.a `lorder _lwp_kill.so _lwp_detach.so
    _lwp_park.so _lwp_unpark.so _lwp_unpark_all.so|tsort`
 [/opt/obj/lib/libc]> /opt/tools/bin/i386--netbsdelf-ranlib
    libpthread_lwp_stubs.a
 [/opt/obj/lib/libc]> /opt/tools/bin/i386--netbsdelf-gcc -Wl,-nostdlib
    -B/opt/obj/destdir.i386/usr/lib/ -B/opt/obj/destdir.i386/usr/lib/
    -Wl,-rpath-link,/opt/obj/destdir.i386/lib:/opt/obj/destdir.i386/usr/lib
    -R/lib  -L/opt/obj/destdir.i386/lib  -Wl,-x -shared
    -Wl,-soname,libpthread_lwp_stubs.so.0   -o libpthread_lwp_stubs.so.0
    -Wl,--whole-archive test.a  -Wl,--no-whole-archive
    -L/opt/obj/destdir.i386/usr/lib

 - copied libpthread_lwp_stubs.so.0 into /usr/lib in the chroot,

 - copied the libpthread.so.0.7 from -current and changed symlinks
(Continue reading)

Permalink | Reply | 2 comments |
headers
Quentin Garnier | 5 Mar 2007 08:29

Re: Removal of SA vs. icky libc ABI breakage

On Mon, Mar 05, 2007 at 02:46:39AM +0100, Lubomir Sedlacik wrote:
> On Sun, Mar 04, 2007 at 06:47:58PM +0000, David Laight wrote:
> > I think that it may only be necessary to create a small .so containing
> > the new syscall stubs.  Then only the new libpthread would be needed.
> > 
> > Maybe ld.so.conf could get the library loaded, alternatively it could
> > be built with a .SONAME matching that of libpthread, with a .NEEDED
> > entry to pull in the new libpthread itself.
> 
> both ways work, i just tested.  here's what i did.

Yes, but it was very much expected.  The question is:  what's easier?
libc, libcrypt and libpthread are part of a normal build, as we do every
week, so distribution is not a problem.  I don't see how we would build
that small .so, except as a one time thing and provide just the binary
on the site.  Less than ideal.

[...]
> but these work only for the load time.  how would you solve the issue at
> the link time?

What kind of issue could there possibly be at link (ld, not ld.so_elf)
time?

--

-- 
Quentin Garnier - cube <at> cubidou.net - cube <at> NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Bouyer | 8 Mar 2007 00:06

Re: Removal of SA vs. icky libc ABI breakage

On Mon, Mar 05, 2007 at 08:29:17AM +0100, Quentin Garnier wrote:
> On Mon, Mar 05, 2007 at 02:46:39AM +0100, Lubomir Sedlacik wrote:
> > On Sun, Mar 04, 2007 at 06:47:58PM +0000, David Laight wrote:
> > > I think that it may only be necessary to create a small .so containing
> > > the new syscall stubs.  Then only the new libpthread would be needed.
> > > 
> > > Maybe ld.so.conf could get the library loaded, alternatively it could
> > > be built with a .SONAME matching that of libpthread, with a .NEEDED
> > > entry to pull in the new libpthread itself.
> > 
> > both ways work, i just tested.  here's what i did.
> 
> Yes, but it was very much expected.  The question is:  what's easier?
> libc, libcrypt and libpthread are part of a normal build, as we do every
> week, so distribution is not a problem.  I don't see how we would build
> that small .so, except as a one time thing and provide just the binary
> on the site.  Less than ideal.

I'd still like to see it available somewhere, for the benefit of pkg_comp
users at last. For example, right now the 2.1/i386 and /sparc binary
in pub/pkgsrc/ are built in a chroot on a box running netbsd-3 kernels
(for various reasons, I can't use netbsd-2 kernels on these boxes).
I may have to do the same in the future to build 3.x and 4.x binary
packages.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain Hibbert | 9 Mar 2007 17:22

group name/gid expiry?

Hi,
   I am looking at adding an option "-G group" to sdpd(8) to allow members
of the specific group to modify the database, so that for instance you
don't need root privileges to run programs which register a service and
wait for bluetooth connections.

   Is it ok to cache a gid returned from getgrnam(3) during the setup, or
should I check it on each open, in case it changed?

iain
Permalink | Reply | 1 comment |
headers
Greg Troxel | 9 Mar 2007 21:25
Picon

Re: group name/gid expiry?

Iain Hibbert <plunky <at> rya-online.net> writes:

>    I am looking at adding an option "-G group" to sdpd(8) to allow members
> of the specific group to modify the database, so that for instance you
> don't need root privileges to run programs which register a service and
> wait for bluetooth connections.
>
>    Is it ok to cache a gid returned from getgrnam(3) during the setup, or
> should I check it on each open, in case it changed?

I wonder if there should be some way for user space to invoke kauth
ops in the kernel; you're adding an ad hoc mechanism (which seems
useful and reasonable) to implement ACLs.  It would be nice if there
were a more uniform way, even across the kernel/user boundary.
Permalink | Reply | 0 comments |
headers
Bill Stouder-Studenmund | 13 Mar 2007 06:41
Picon

Irritation with shutdown(8) and postgress rc.d script

I have a box on which I run PostgreSQL. I'm using the rc.d script that 
came with the pkgsrc server I installed. I'm in the operator group. I can 
run shutdown(8) and turn off the computer.

The problem is when it comes time to stop postgres. Postgress likes to be 
running as the postgress user (pgsql here). So it does a su pgsql to tell 
the system to shutdown.

Well. The problem is that when I run shutdown and shutdown runs rc.d 
hooks, su notices that I'm me and not root, so it asks for pgsql's 
password. Well, I've forgotten it. So PostgreSQL gets a hard shutdown.

I chatted with John Nemeth, who indicated that su is calling into PAM, and 
pam_rootok only checks the real id.

For my case the effective ID is roots, but the real is my own.

How do we fix this? I can turn off the computer, so why are we not letting 
me stop services? :-)

Options:

1) Make pam_rootok check effective too.

2) Add pam_effectiverootok which checks effective id.

3) Make shutdown set its real id to root as well.

I prefer (1) since if my effective id is root, I am acting as root. I can 
turn off the box, so it makes little sense to not let me do other root
(Continue reading)

Permalink | Reply | 0 comments |

Gmane