Re: SGID/SUID on scripts
On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: per...@pluto.rain.com writes: [snip description of shell opening a script, finding a #! line and passing a file descriptor for the opened script to the intended interpreter in /dev/fd/, to avoid a race condition where the shell opens the script, reads the #! line, closes it and hands off the filename to the intended interpreter to reopen what may now be a different file] I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD (albeit as a kernel compile-time option in the latter two). (It's apparently also in IRIX and UnixWare). Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I never ask myself if I'm being paranoid, but if I'm being paranoid enough!) I'd have thought they would have explored the implications fully. Certainly other stuff knows about it. As I said yesterday, Perl describes the problem in its perlsec manpage/perldoc. The perl interpreter even has a build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is supposedly detected as part of configure. There may well be some problems to overcome, but this doesn't appear to be unexplored territory. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SGID/SUID on scripts
Ivan Voras ivo...@freebsd.org wrote: 2009/7/23 per...@pluto.rain.com: Ivan Voras ivo...@freebsd.org wrote: Presumingly, the biggest concern is with scripts owned by root. Who can unlink, move or change the script? The owner and his group can change it; the directory owner can unlink it ... Anyone can make a link to such a script in, say, /tmp and then mess with the link :( You mean setuid a soft link? That's allowed? One can certainly make a symlink that points to a setuid file. The permissions of the symlink itself don't matter. IIRC the original demonstration that this exposure was real and not just theoretical involved making -- and subsequently messing with -- a hard link in /tmp to a setuid script in /bin, /tmp and /bin both being on the root FS. (This was before machines commonly had enough RAM for tmpfs to be practical, and may have been before symlinks even existed.) Granted a case can be made for making /tmp a separate FS in any event, but of course it would have worked just as well to make a link in /usr/tmp to a setuid script in /usr/bin, etc. The only way to avoid the exposure would have been to ensure that no possible attacker would have write permission to any directory on the same FS as a setuid script to which the attacker had execute permission -- not the easiest thing to keep track of on an ongoing basis. With the existence of symlinks I suspect even that would no longer help. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. Thanks. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. pgp7Qk5S94jFN.pgp Description: PGP signature
Re: checking number of parallel ports installed and their port adresses
thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big. uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. cheers. alex John Baldwin schrieb am 2009-07-23: On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: the ppi manual states that using ioctl with /dev/ppi is extremely slow. i need the parallel port to be really fast. i need to communicate with a device that uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full ISA bus speed to be able to push/pull data to/from the parallel port without any delays. timing is really critical. if there's a lot of work to do for the scheduler and the io calls get queued too long the transfer will fail. The overhead of ppi is probably in the noise on a modern CPU. I think you should be fine with just using ppi(4). actually i meant: how can i check the available parallel ports from within my app? is there a syscall i can use or something like that? You can look for ppcX devices perhaps. The easiest way might be to enable ppi and look for /dev/ppiX devices in /dev. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
* Jeremie Le Hen jere...@le-hen.org wrote: On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Very short answer: yes! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpXiKMuleZca.pgp Description: PGP signature
Re: concurrent sysctl implementation
On Fri, Jul 24, 2009 at 01:54:04PM +0200, Jeremie Le Hen wrote: On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? The aux entries are not hints, and they are put on the new image stack when execve() activates the image. Aux entries has nothing to do with static link time, they are supplied to the dynamic linker (ELF interpreter). pgpFY5GAPaI2S.pgp Description: PGP signature
Re: concurrent sysctl implementation
On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: * Jeremie Le Hen jere...@le-hen.org wrote: On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Very short answer: yes! Ok thanks. But this would make stack protection useless for local attacks on suid binaries that are world-readable since the attacker could read the ELF aux vector and compute the canary. Upon each invocation, the canary would stay the same which makes the repeat-until-success attack feasible for daemons that are automatically respawned. This saves one syscall per exec(2) but reduce security for the two cases described above. In the performance test I've run with and without -fstack-protector to build world, I saw only around 1 percent penalty. I must admit this was on a UP system which wasn't loaded though. I know that the sysctl system may be redesigned in the future to allow more concurrency. Is it something that could prevent from changing the way the canary is initialized? Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
* Jeremie Le Hen jere...@le-hen.org wrote: On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: * Jeremie Le Hen jere...@le-hen.org wrote: On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Very short answer: yes! Ok thanks. But this would make stack protection useless for local attacks on suid binaries that are world-readable since the attacker could read the ELF aux vector and compute the canary. Wait wait wait. It seems you were only partially right (and Kostik corrected you): We could add AT_RANDOM, but this value will be filled in by the kernel when starting the process. This means the random value is not stored in the binary. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpkPBdmMkXBL.pgp Description: PGP signature
Re: checking number of parallel ports installed and their port adresses
On Friday 24 July 2009 6:42:34 am Alexander Best wrote: thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big. uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. Hmmm, that is a bit much. Though I do suppose you are incurring a user - kernel - user transition for each I/O access. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: checking number of parallel ports installed and their port adresses
well i'm performing a large number of port accesses since the data gets transferred bit-by-bit over a single parallel port pin with another pin acting as clock. so transfering 256 kbyte of data means i'm doing = 256*1024*8*2 ioctls. i guess when transfering data on a nibble, byte, word or dword basis the overhead isn't that dramatic. alex John Baldwin schrieb am 2009-07-24: On Friday 24 July 2009 6:42:34 am Alexander Best wrote: thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big. uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. Hmmm, that is a bit much. Though I do suppose you are incurring a user - kernel - user transition for each I/O access. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote:
On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote:
John, apparently you sent me an email (thanks a lot) which I never
received (we have to blame our company's spam filters which I do
not control). I'll comment on it here in my reply to Doug...
Yes, I saw the bounces. Hopefully you see the list version of this.
Yes, I've been lucky this time.
| Did you try
| doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in
your
| driver that is a child of hostb0?
I tried this, well, something similar: I had to do 4 times
device_get_parent() to end up at acpi0:
mydriver - hostb0 - pci0 - pcib0 - acpi0
You don't actually need to do that. pci0 will pass the request up to acpi0
That's what I hoped as well.
eventually. You just need to ask pci0 to allocate it for you and it will see
you are not a direct child and take the 'passthrough' case here:
struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
...
if (device_get_parent(child) != dev)
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, the real start address, the real
end address, the length, RF_ACTIVE);
OK, I have modified my driver exactly this way, but still no success.
It seems my code didn't make it to the list (the attachment
was stripped) so I include it inline now. Testing is quite
simple, every feedback is welcome:
1. check if devinfo -r spits out some free I/O memory addresses
ranges under acpi0 with at minimum 4 bytes length.
2. select one of them and assign its start address to rstart in
eccmon_probe() at the line which reads now
u_long rstart = 0xfed14000;
(this is the address I use for testing)
3. compile, kldload and dmesg. I always get the message
bus_alloc_resource() returned NULL.
Thanks,
-Andre
eccmon.c start -
#include sys/param.h
#include sys/systm.h
#include sys/module.h
#include sys/kernel.h
#include machine/bus.h
#include sys/bus.h
#include sys/rman.h
#include machine/pci_cfgreg.h
#include dev/pci/pcivar.h
#include dev/pci/pcireg.h
struct eccmon_softc {
device_t dev;
int res_set;/* flag if bus_set_resource() was used
successfully */
struct resource* res;
int rid;
};
/**/
/* eccmon_probe() */
/**/
static int eccmon_probe( const device_t const dev )
{
u_long rstart = 0xfed14000;
int ret;
struct resource* res;
int rid = 0;
device_printf( dev, probe: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
/*
* try to bus_alloc_resource the resource and give it back
*/
if( (res = BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, rstart, rstart+4, 4, RF_ACTIVE )) == NULL ) {
device_printf( dev, bus_alloc_resource() returned NULL\n );
return ENXIO;
}
if( (ret = BUS_RELEASE_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, res )) != 0 )
device_printf( dev, bus_release_resource() returned %d\n, ret );
return ENXIO;
}
/***/
/* eccmon_attach() */
/***/
static int eccmon_attach( const device_t const dev )
{
device_printf( dev, attach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return ENXIO;
}
/***/
/* eccmon_detach() */
/***/
static int eccmon_detach( const device_t const dev )
{
device_printf( dev, detach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return 0;
}
/*/
/* eccmon_identify() */
/*/
static void eccmon_identify( driver_t *driver, device_t p )
{
device_printf( p, identify: start: %x %x\n, pci_get_vendor( p ),
pci_get_device( p ) );
device_printf( p, identify on: %s %d\n, device_get_name( p ),
device_get_unit(p) );
if( device_find_child( p, eccmon, -1 ) == NULL
strcmp( device_get_name( p ), hostb ) == 0
device_get_unit( p ) == 0 ) {
device_t child = device_add_child( p, eccmon, -1 );
device_printf( p, identify added child: %p\n, child );
}
}
/***/
/* driver(9) stuff */
/***/
static device_method_t eccmon_methods[] = {
DEVMETHOD( device_identify, eccmon_identify ),
DEVMETHOD( device_probe, eccmon_probe ),
DEVMETHOD(
Re: SGID/SUID on scripts
Jonathan McKeown j.mcke...@ru.ac.za writes: On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD (albeit as a kernel compile-time option in the latter two). (It's apparently also in IRIX and UnixWare). Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I never ask myself if I'm being paranoid, but if I'm being paranoid enough!) I'd have thought they would have explored the implications fully. They don't enable it by default, and they don't seem to recommend it. Certainly other stuff knows about it. As I said yesterday, Perl describes the problem in its perlsec manpage/perldoc. The perl interpreter even has a build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is supposedly detected as part of configure. The problem I'm wondering about is that it doesn't matter what knows about it as long as there's an interpreter that *doesn't*. Anything that opens a script parameter on its own (there are other vulnerable approaches, but one's enough) will be insecure. I may well be missing something, of course. There may well be some problems to overcome, but this doesn't appear to be unexplored territory. Not entirely, but there may well be a reason it's never been in common use. - Lowell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: concurrent sysctl implementation
On Fri, Jul 24, 2009 at 03:49:53PM +0200, Ed Schouten wrote:
* Jeremie Le Hen jere...@le-hen.org wrote:
On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote:
* Jeremie Le Hen jere...@le-hen.org wrote:
On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote:
On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote:
Hi Ed,
Sorry for the late reply.
On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote:
We probably could. I think I discussed this with Robert Watson
some time
ago and we could use things like ELF hints. But still, that
doesn't
prevent us from reaching this limitation later on.
Can you elaborate a little? Are you talking about elf-hints.h?
I don't see where we can get randomness from it.
The thing is called ELF auxillary information vector. It is used to
supply some useful information for interpreter from the kernel,
see include/machine/elf.h for AT_* entries.
Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM,
generated at link time, that will be used to fill the canary at exec(2)
time?
Very short answer: yes!
Ok thanks. But this would make stack protection useless for local
attacks on suid binaries that are world-readable since the attacker
could read the ELF aux vector and compute the canary.
Wait wait wait. It seems you were only partially right (and Kostik
corrected you):
We could add AT_RANDOM, but this value will be filled in by the kernel
when starting the process. This means the random value is not stored in
the binary.
Below is the prototype that seems to work for me both with patched and
old rtld on i386. Patch also contains bits for amd64 that I did not
tested yet. All other arches are not buildable for now.
Patch completely eliminates sysctl syscalls from the rtld and libc
startup. Without the patch, a single run of /bin/ls did 6 sysctls,
with the patch, no sysctls is queried at all.
diff --git a/lib/libc/gen/__getosreldate.c b/lib/libc/gen/__getosreldate.c
index 69aac07..6a4e5ea 100644
--- a/lib/libc/gen/__getosreldate.c
+++ b/lib/libc/gen/__getosreldate.c
@@ -29,6 +29,8 @@ __FBSDID($FreeBSD$);
#include sys/param.h
#include sys/sysctl.h
+#include errno.h
+#include link.h
/*
* This is private to libc. It is intended for wrapping syscall stubs in order
@@ -49,7 +51,15 @@ __getosreldate(void)
if (osreldate != 0)
return (osreldate);
-
+
+ if (_rtld_aux_info != NULL)
+ error = _rtld_aux_info(AT_OSRELDATE, osreldate,
+ sizeof(osreldate));
+ else
+ error = ENOSYS;
+ if (error == 0 osreldate != 0)
+ return (osreldate);
+
oid[0] = CTL_KERN;
oid[1] = KERN_OSRELDATE;
osrel = 0;
diff --git a/lib/libc/gen/getpagesize.c b/lib/libc/gen/getpagesize.c
index d796b9d..b8f0ec1 100644
--- a/lib/libc/gen/getpagesize.c
+++ b/lib/libc/gen/getpagesize.c
@@ -36,6 +36,8 @@ __FBSDID($FreeBSD$);
#include sys/param.h
#include sys/sysctl.h
+#include errno.h
+#include link.h
#include unistd.h
/*
@@ -52,13 +54,23 @@ getpagesize()
int mib[2];
static int value;
size_t size;
+ int error;
+
+ if (value != 0)
+ return (value);
+
+ if (_rtld_aux_info != NULL)
+ error = _rtld_aux_info(AT_PAGESZ, value, sizeof(value));
+ else
+ error = ENOSYS;
+ if (error == 0 value != 0)
+ return (value);
+
+ mib[0] = CTL_HW;
+ mib[1] = HW_PAGESIZE;
+ size = sizeof value;
+ if (sysctl(mib, 2, value, size, NULL, 0) == -1)
+ return (-1);
- if (!value) {
- mib[0] = CTL_HW;
- mib[1] = HW_PAGESIZE;
- size = sizeof value;
- if (sysctl(mib, 2, value, size, NULL, 0) == -1)
- return (-1);
- }
return (value);
}
diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c
index 270d641..e479abe 100644
--- a/lib/libc/stdlib/malloc.c
+++ b/lib/libc/stdlib/malloc.c
@@ -179,6 +179,7 @@ __FBSDID($FreeBSD$);
#include errno.h
#include limits.h
+#include link.h
#include pthread.h
#include sched.h
#include stdarg.h
@@ -4769,7 +4770,10 @@ malloc_init_hard(void)
unsigned i;
int linklen;
char buf[PATH_MAX + 1];
+ int mib[2];
+ size_t len;
const char *opts;
+ int error;
malloc_mutex_lock(init_lock);
if (malloc_initialized) {
@@ -4782,10 +4786,11 @@ malloc_init_hard(void)
}
/* Get number of CPUs. */
- {
- int mib[2];
- size_t len;
-
+ if (_rtld_aux_info != NULL)
+ error = _rtld_aux_info(AT_NCPUS, ncpus, sizeof(ncpus));
+ else
+ error = ENOSYS;
+ if (error != 0 || ncpus == 0) {
Re: SGID/SUID on scripts
On Wed, Jul 22, 2009 at 2:42 PM, Anthony Pankova...@mail.ru wrote: SGID/SUID bits don't work with shell scripts, do they? No. A possible workaround is have a SUID/SGID version of you interpreter and use it. Something like # pw groupadd -n sush -g 401 # cp /bin/sh /bin/sush # chown root:sush /bin/sush # chmod 4750 /bin/sush # pw usermod johndoe -G sush Then start your script with #!/bin/sush and user johndoe,as well as any member of the sush group will be able to it run as root. I think I don't need to warn you that they will be able to run *any* command as root, in fact. For a better approach, consider using sudo, instead (/usr/ports/security/sudo). -- My preferred quotation of Robert Louis Stevenson is You cannot make an omelette without breaking eggs. Not because I like the omelettes, but because I like the sound of eggs being broken. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
