Re: Just a wild idea
I've been playing with jails for over 2 years now. I really like them but we often use them to run a process as root with reduced power only to get access to TCP and UDP ports below 1024. For many applications however, for example lpd, named, sendmail, tac_plus and others, it would be more than good enough to run that program as a normal, non-root user provided there is a way to bind to that single low TCP and/or UDP port that the program needs access to. better to have a definition of what are restricted ports for each jail than to redefine what root is (1024 numbers is only 32 words of bitmask) Sometimes I think the below 1024 check is outdated. What about a flag to switch the below 1024 check totally off? How much do we really loose? The two most common setups are probably a single user desktop and a server box doing something like mail, web or dns. On the desktop switching the below 1024 check off only gain the user (who is also root) something, he needs to su less. In a server environment, access to the box is normally controlled in anycase, so the people who have access to the box, normally also are the ones that have the root password or whatever is needed to (re)start those services. The only place where I think the check might still be usefull, is on a general shell login box. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Just a wild idea
On Mon, Sep 23, 2002 at 08:29:15AM +0200, John Hay wrote: better to have a definition of what are restricted ports for each jail than to redefine what root is (1024 numbers is only 32 words of bitmask) Sometimes I think the below 1024 check is outdated. What about a flag to switch the below 1024 check totally off? How much do we really loose? The I remember around 6 years ago, when I still ran Linux, that the solution to this problem came in the form of a diff which delegated bind() on a reserved port credentials to a certain GID, BIND_GID. From that point on, the boot process had to be changed such that daemons which only needed to bind to a privileged port were run under their own non-root uid, with this BIND_GID in the additional groups list, using a wrapper such as sudo. This still amounts to a local mod - it can be done, has been done before, I think Tom Ptacek did some diffs for this for vanilla 4.4BSD a good while back, rewriting it for your current tree can't be too difficult. See here: http://www.sockpuppet.org/tqbf/sysctlpriv.html BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Just a wild idea
On Sun, 22 Sep 2002, Juli Mallett wrote: Maybe just replace all suser(9) uses with MAC credential checks, and install MAC_UNIX by default, which would be set up to behave like ye olden UNIX... Who knows. Something like that sounds like a really good idea. I'd like to see this not only for binding to low ports but also, for example, to set the system time -- this would let you run ntpd as non-root. It'd be interesting to have a system one day where once you've gone past single user mode, root drops all its privs and acts just like a normal user account and daemon accounts only have special privs handed out to them in little chunks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
subscription required?
Hi, does this list require subscription to allow posts? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL doesn't say so, but neither of my two attempts (before I subscribed) has shown up in the archives. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 1:55PM up 5 days, 21:10, 22 users, load averages: 0.00, 0.01, 0.04 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
fifo kqfilter change in rev. 1.54?
Hi, I'm currently testing stuff on NetBSD kqueue branch, and came over FreeBSD change in rev. 1.54 of src/sys/fs/fifofs/fifo_vnops.c . I can't figure out what this change exactly fixes, since things seem to work fine without the change - the code on NetBSD kqueue branch uses still fi_readsock always, and this seems to work fine for both EVFILT_READ and EVFILT_WRITE. At the very least, I believe the change should have been to use fi_writesock for EVFILT_READ and fi_readsock for EVFILT_WRITE. Then the explicit added sorwakeup() calls would probably not be necessary, since the wakeup would be done by generic code.[*] But in any case, using fi_readsock should be fine. What am I missing here? Thanks for reply, Jaromir P.S. I also believe the added so?wakeup() calls should use fi_readsock in one case and fi_writesock in the other, not fi_writesock in both cases. -- Jaromir Dolecek [EMAIL PROTECTED]http://www.NetBSD.org/ -=- We should be mindful of the potential goal, but as the tantric-=- -=- Buddhist masters say, ``You may notice during meditation that you -=- -=- sometimes levitate or glow. Do not let this distract you.'' -=- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Problems catching SIGPIPE when writing to a broken stream
Hi hackers, I'm implementing a programmme, which writes a big amount of data (using write(2)) to a socket. When the communication stream has been closed by some reason, during the write(2) call, my process receives SIGPIPE. I tryed to catch it with signal(3) and change the behaviour of write(2) call with siginterrupt(3), but SIGPIPE is still raised to my process and terminates it. Any help and ideas will be useful! regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problems catching SIGPIPE when writing to a broken stream
On Mon, Sep 23, 2002 at 04:34:18PM +0300, Vladimir Terziev wrote: Hi hackers, I'm implementing a programmme, which writes a big amount of data (using write(2)) to a socket. When the communication stream has been closed by some reason, during the write(2) call, my process receives SIGPIPE. I tryed to catch it with signal(3) and change the behaviour of write(2) call with siginterrupt(3), but SIGPIPE is still raised to my process and terminates it. Any help and ideas will be useful! You should receive a short write(2) before the SIGPIPE is sent, most probably a write() which returns -1 and sets errno to, say, ECONNRESET or something like that. Are you sure *all* your previous writes return as many bytes as you have tried to write? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? msg36996/pgp0.pgp Description: PGP signature
two make questions
Hi, I've sent two messages about (p)make to questions@ but have not received any replies, so I ask here. I'm not a C programmer (thus not really familiar with make), and I'm trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. Also, since two attempts sent to this list before I subscribed haven't make it through and I'm not sure about the cause, I'm just posting links to the original messages in questions@: http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 Hope you don't mind, and thanks. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 7:19PM up 5 days, 2:34, 21 users, load averages: 0.00, 0.01, 0.00 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problems catching SIGPIPE when writing to a broken stream
On Mon, Sep 23, 2002 at 04:42:25PM +0300, Peter Pentchev wrote: On Mon, Sep 23, 2002 at 04:34:18PM +0300, Vladimir Terziev wrote: Hi hackers, I'm implementing a programmme, which writes a big amount of data (using write(2)) to a socket. When the communication stream has been closed by some reason, during the write(2) call, my process receives SIGPIPE. I tryed to catch it with signal(3) and change the behaviour of write(2) call with siginterrupt(3), but SIGPIPE is still raised to my process and terminates it. Any help and ideas will be useful! You should receive a short write(2) before the SIGPIPE is sent, most probably a write() which returns -1 and sets errno to, say, ECONNRESET or something like that. Are you sure *all* your previous writes return as many bytes as you have tried to write? Hit ':wq' too fast ;) You might want to look into scheduling your write(2) calls only when possible, using either select(2) or poll(2) to check the network socket for writability. G'luck, Peter PS. Wow. 'look writa' returned both 'writable' and 'writability'. 'look writea' returned 'writeable', but not 'writeability'. Strike another one for English grammar ;) -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. msg36998/pgp0.pgp Description: PGP signature
Re: two make questions
On Mon, 23 Sep 2002, Roman Neuhauser wrote: Hi, I've sent two messages about (p)make to questions@ but have not received any replies, so I ask here. I'm not a C programmer (thus not really familiar with make), and I'm trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. Also, since two attempts sent to this list before I subscribed haven't make it through and I'm not sure about the cause, I'm just posting links to the original messages in questions@: http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 10:06:12 -0400: On Mon, 23 Sep 2002, Roman Neuhauser wrote: I'm not a C programmer (thus not really familiar with make), and I'm trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck, thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. Again, thanks, and HAND. Also, I couldn't find on freebsd.org whether it's required to group-reply on hackers@ (as it is on questions@), so I'm cc'ing you. Sorry if this is not required. You don't need to cc me either way. Roman -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 4:17PM up 5 days, 23:32, 22 users, load averages: 0.03, 0.11, 0.07 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
periodic(8)-produced diffs
[repost from questions@; no replies received since 2002-09-17]
Hi there,
various /etc/periodic scripts mail root diffs of a few config files etc.
grep on my (quite fresh) STABLE box shows that except for
/etc/periodic/daily/210.backup-aliases, all the diff invocations use the
old format. I have two issues with this: first, all the diffs should be
in the same format, and second, root should be able to select their
preferred format in /etc/periodic.conf (yes, i have difficulty reading
anything but unified diffs).
Now, before I go and produce a patch, would such a change be actually
welcome, or am I going to get shot down?
And, what would the preferred interface be? Most of periodic.conf knobs
are bools, but I'm not sure
diff_{context,traditional,unified}_format={YES,NO}
is better than
diff_format={context,traditional,unified}
What do you think?
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
5:03PM up 6 days, 18 mins, 22 users, load averages: 0.03, 0.11, 0.08
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Mon, Sep 23, 2002 at 04:35:23PM +0200, Roman Neuhauser wrote: thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Yeah, it takes a bit of getting used to. Make lets you define a dependency graph, and various transformations/instructions that can be applied to each node in that graph. In that respect it's more like a Caesar salad, the dependencies are the lettuce and the variables are croutons. Making it work is the dressing; you have to add it yourself ;-) Managing Projects with Make from O'Reilly is a good introduction but it's a tad dated. Also, make has a habit of being different from one platform to the next. I particularly like the BSD pmake, but Solaris make is different still, and GNU make is a law unto itself. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. The scope of a Makefile macro (variable) seems to be limited to the current invocation, unless you explicitly export things as environment variables, or set them on a command line when re-invoking Make. Depending on what you want to do this can get quite complicated. Have a look at /usr/src/Makefile which actually reinvokes itself quite a bit (and includes things from Makefile.inc which may *also* do that!). Nik Clayton mentioned a tool to automatically diagram makefile dependency graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I can't recall its name. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. If you're including any standard makefile templates you may wish to review those; as well as /etc/make.conf and /etc/defaults/make.conf. You probably also want to look at the MAKEOBJDIRPREFIX behaviour in the make(1) man page. BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: periodic(8)-produced diffs
On Mon, Sep 23, 2002 at 05:05:36PM +0200, Roman Neuhauser wrote:
[... re periodic diffs]
And, what would the preferred interface be? Most of periodic.conf knobs
are bools, but I'm not sure
diff_{context,traditional,unified}_format={YES,NO}
is better than
diff_format={context,traditional,unified}
No reason why rc.conf knobs *have* to be bools, what ultimately matters is
the case...esac which parses them. I'd avoid relying on a default value
in /etc/defaults/rc.conf for the sake of robustness.
I prefer unified diffs, personally.
BMS
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 16:08:11 +0100:
On Mon, Sep 23, 2002 at 04:35:23PM +0200, Roman Neuhauser wrote:
thanks a lot for your reply. You're right: I'm viewing Makefiles
as sequential programs, which obviously (even to me) is not quite
true, but I'm having difficulty getting rid of this.
Yeah, it takes a bit of getting used to. Make lets you define a dependency
graph, and various transformations/instructions that can be applied to
each node in that graph. In that respect it's more like a Caesar salad,
the dependencies are the lettuce and the variables are croutons. Making it
work is the dressing; you have to add it yourself ;-)
:)
Managing Projects with Make from O'Reilly is a good introduction but it's
a tad dated.
yeah, i'll be ordering it shortly.
Also, make has a habit of being different from one platform to the
next. I particularly like the BSD pmake, but Solaris make is different
still, and GNU make is a law unto itself.
i know. i'm limiting myself to pmake atm, so other implementations
are out of the scope of my questions.
Now, saying don't do it is nice, but I'd like to know why. Why
doesn't this work? Also, what documentation (besides the source) is
there that covers variable scopes? See the second message for the
problem description.
The scope of a Makefile macro (variable) seems to be limited to the current
invocation,
? see below
unless you explicitly export things as environment variables,
or set them on a command line when re-invoking Make.
i'm not sure what to take of this. consider this makefile:
DESTDIR=
SOURCES=foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
SRCFILE=${.TARGET:C,^${DESTDIR}/,,}
.BEGIN:
@echo \$${DESTDIR}: ${DESTDIR}
@echo \$${TARGETS}: ${TARGETS}
all: ${TARGETS}
${TARGETS}: ${SRCFILE}
@echo SRC: ${SRCFILE} - TGT: ${.TARGET}
.PHONY: all ${TARGETS}
roman@freepuppy ~/tmp 1133:0 make all DESTDIR=/tmp/maketest
${DESTDIR}: /tmp/maketest
${TARGETS}: /foo /bar /baz
Graph cycles through /foo
Graph cycles through /bar
Graph cycles through /baz
`all' not remade because of errors.
roman@freepuppy ~/tmp 1133:0
in the invocation above, the commandline assignment overrode the
Makefile value of DESTDIR in the .BEGIN target, but not outside it
(or presumably any target), in the ${TARGETS} and ${SRCFILE} macros.
So: what exactly do you mean by the current invocation?
Depending on what you want to do this can get quite complicated. Have
a look at /usr/src/Makefile which actually reinvokes itself quite a
bit (and includes things from Makefile.inc which may *also* do that!).
I've had more than a few looks in /usr/ports/Mk/bsd.port.mk, but
getting the building block principles from something that
complicated is not easy.
Nik Clayton mentioned a tool to automatically diagram makefile dependency
graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I
can't recall its name.
I'll google, thanks.
I can fix the behavior with conditional assignment to DESTDIR (?=)
in the Makefile, but still would like to understand what's causing
make to behave the way it does.
If you're including any standard makefile templates you may wish to
review those; as well as /etc/make.conf and /etc/defaults/make.conf.
nothing like that. my Makefiles break withoug the need for this
stuff. :)
You probably also want to look at the MAKEOBJDIRPREFIX behaviour in
the make(1) man page.
will do so.
thanks!
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
5:23PM up 6 days, 38 mins, 22 users, load averages: 0.11, 0.07, 0.04
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
[sent only to Chad by mistake]
# [EMAIL PROTECTED] / 2002-09-23 10:35:54 -0600:
On Mon, Sep 23, 2002 at 05:35:16PM +0200, Roman Neuhauser wrote:
unless you explicitly export things as environment variables,
or set them on a command line when re-invoking Make.
i'm not sure what to take of this. consider this makefile:
DESTDIR=
SOURCES=foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
SRCFILE=${.TARGET:C,^${DESTDIR}/,,}
.BEGIN:
@echo \$${DESTDIR}: ${DESTDIR}
@echo \$${TARGETS}: ${TARGETS}
all: ${TARGETS}
${TARGETS}: ${SRCFILE}
@echo SRC: ${SRCFILE} - TGT: ${.TARGET}
.PHONY: all ${TARGETS}
roman@freepuppy ~/tmp 1133:0 make all DESTDIR=/tmp/maketest
${DESTDIR}: /tmp/maketest
${TARGETS}: /foo /bar /baz
Graph cycles through /foo
Graph cycles through /bar
Graph cycles through /baz
`all' not remade because of errors.
roman@freepuppy ~/tmp 1133:0
How about something like this:
#DESTDIR= This overrides the command line setting.
As I said earlier, with DESTDIR= in the Makefile, .BEGIN still
displays the value passed on the command line. These two things
(your statement, and the observed behavior) seem to contradict each
other.
Wait, I know the assignment in my Makefile overrides the commandline
assignment: but only outside targets. I just wanted to point out
that going into a bit more detail can save quite an amount of
confusion. :)
#DESTDIR?=/my/default might work better?
SOURCES= foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
# Note: SRCFILE is evaluated at startup, which results in as .TARGET
# is not yet defined, and then it is evaluated in each target..
yup, per the man page.
# Note that DESTDIR will be overriden by the define at the top by the
# time we get into a target.
i'm not sure i'm reading this right, but if i am, you're saying the
opposite of what i'm seeing: DESTDIR is overriden by the command
line assignment.
[further explanation snipped]
Good luck, and I hope that helps.
you bet! awesome, thanks!
Nik Clayton mentioned a tool to automatically diagram makefile dependency
graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I
can't recall its name.
I'll google, thanks.
Let me know if you find this :)
yeah, i'm aware i don't have much to google for. :)
btw, i'm sure i'll run into other delicate features in pmake. is it
okay for me to continue asking here? questions@ doesn't seem to be
*the* place.
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
6:49PM up 6 days, 2:04, 29 users, load averages: 0.00, 0.04, 0.06
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Mon, 23 Sep 2002, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2002-09-23 10:06:12 -0400: On Mon, 23 Sep 2002, Roman Neuhauser wrote: I'm not a C programmer (thus not really familiar with make), and I'm I am a C programmer, and one of my strengths is that I know make pretty well. trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck, thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. Wish I could give you some satisfaction because I've been there, done that. Unfortunately, you aren't going to find it. If you decide that the only thing that you can do is fix the docs, you won't even succeed there, because it will only raise a huge volume of complaints (seemingly endless nitpickers) all giving their own take on it, even though they won't fix it themselves. The only book there is on make is pretty pissed-poor, the make book from O'Reilly. I've been considering writing a book on the 3 main flavors of make for a while now I'm not convinced yet that there's a market for it. I'm pretty sure now, with all the horrible make projects I've undertaken, I could do it. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. The odd behavior of variables is only one item from a whole list of them. Go take a look at what use: means, if you want a headache. Or, how about the behavior of include, which *does* work, even though the man page says that only .include will work (include is compatible with both BSD make and GNU make, an important point.) When you don't have any problem with a file like bsd.port.mk, then you'll be able to claim to know make. Again, thanks, and HAND. Also, I couldn't find on freebsd.org whether it's required to group-reply on hackers@ (as it is on questions@), so I'm cc'ing you. Sorry if this is not required. You don't need to cc me either way. Roman Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Just a wild idea
* De: Lamont Granquist [EMAIL PROTECTED] [ Data: 2002-09-23 ] [ Subjecte: Re: Just a wild idea ] On Sun, 22 Sep 2002, Juli Mallett wrote: Maybe just replace all suser(9) uses with MAC credential checks, and install MAC_UNIX by default, which would be set up to behave like ye olden UNIX... Who knows. Something like that sounds like a really good idea. I'd like to see this not only for binding to low ports but also, for example, to set the system time -- this would let you run ntpd as non-root. It'd be interesting to have a system one day where once you've gone past single user mode, root drops all its privs and acts just like a normal user account and daemon accounts only have special privs handed out to them in little chunks. One day? It's really easy to do, especially once you have a way for init to set privs for the children easily, and you can just have your rc scripts work with init. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Just a wild idea
On Sun, Sep 22, 2002 at 04:14:53PM +0200, Paul Schenkeveld wrote: I've been playing with jails for over 2 years now. I really like them but we often use them to run a process as root with reduced power only to get access to TCP and UDP ports below 1024. For many applications however, for example lpd, named, sendmail, tac_plus and others, it would be more than good enough to run that program as a normal, non-root user provided there is a way to bind to that single low TCP and/or UDP port that the program needs access to. Exactly. It would be great to have the capabilities implemented in -stable ;) I've written a kernel module for -stable You may be interested in. With it You can for example let specified euids bind to the reserved TCP/UDP ports. It's fully managed via sysctl. It also doesn't affect jails. It's still under development but I use it e.g. to let my non-root chrootuided syslogd bind to its port :) All the effort is in fact sysctl fgc.net_bind.udp.acl=[60514:514] where 60514 is syslogd user's uid. The crazy syslogd story is here: http://bsd.krakow.pl/syslogd.html and the fgc sources.. cvs -d:pserver:[EMAIL PROTECTED]:/cvs/fgc co fgc You may also consider using the TrustedBSD-cap stuff and give the syslogd binary CAP_NET_BIND_SERVICE capability.. but that's still -current. Another possibility of giving a regular user some of the superuser powers is CerbNG (http://cerber.sourceforge.net), but I'm not sure if Pawel has already implemented the bind() stuff.. It's definetely more advanced and more complete security solution for -stable than my per euid/per group capabilities and it's also still under development. With that You can create per binary security policies including restricting access to selected syscalls and granting additional access to other, superuser-reserved syscalls. .. and probably many other things that I'm not aware of :)) -- Micha Belczyk msg37008/pgp0.pgp Description: PGP signature
Re: Practical limit for pre-loaded md_image size?
I'm copying this to -hackers as well. I tried setting the MD_NSECT to 307200 to accomodate my RAM disk, but according to md(4): At boot time the md driver will search for pre-loaded modules of type `md_image' and instantiate a md device for each of these modules. The type `mfs_root' is also allowed for backward compatibility. These devices are backed by the RAM reserved by the loader(8), and as such not limited by the malloc(9) size constraints. I am preloading the images using the md_image variable in loader.conf, so this documentation thinks I *should* be fine. The kernel with MD_NSECT set to 307200 still failed to boot with my 128MB md_image. I'm attaching my kernel config. -nick On Mon, Sep 23, 2002 at 02:08:11PM -0400, Lowell Gilbert wrote: Nicholas Esborn [EMAIL PROTECTED] writes: I've tried this on two machines: 1 4.7-RC w/ 512 MB of RAM 2 5.0-CURRENT w/ 256 MB of RAM Both behave the same way with a ~128MB md_image. Did you check the manual? It says: The default maximum size of a md disk backed by malloc(9) is 20,000 sectors of 512 bytes each. This can be changed with the kernel option MD_NSECT. -nick On Sun, Sep 22, 2002 at 11:19:18AM -0700, Kris Kennaway wrote: On Sun, Sep 22, 2002 at 01:11:20AM -0700, Nicholas Esborn wrote: Hello, I've been trying to boot a kernel and a preloaded md_image of about 128MB. The kernel and image load, and then about a quarter of a second after the kernel executes, before any text even prints, the machine reboots. Has anyone had better luck with large md_image root filesystems? You forgot to mention how much RAM you have, and what FreeBSD version. -- Nicholas Esborn Unix Systems Administrator Berkeley, California # # COPPER # Tue Apr 23 05:41:01 GMT 2002 # nick # # Based on $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.40 2002/03/27 02:16:26 dd Exp $ machine i386 cpu I686_CPU ident COPPERX maxusers0 options HZ=1000 #increase clock resolution for polling options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options MD_NSECT=307200 #Maxium MD size options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev options CPU_ENABLE_SSE options CPU_ATHLON_SSE_HACK #optionsBOOTP #optionsBOOTP_NFSROOT #optionsBOOTP_NFSV3 #optionsBOOTP_COMPAT options IPSEC options IPSEC_ESP options IPSEC_DEBUG options IPFILTER options IPFILTER_LOG options DEVICE_POLLING device isa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus #
Which archiver handles the ICE format?
I'm wanting to extract data files off the original Quake 1 CD. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Which archiver handles the ICE format?
In the last episode (Sep 23), Stephen Hocking said: I'm wanting to extract data files off the original Quake 1 CD. Lets just take a look see... All deice does is join the numbered files together, then execute the result. quake101.1 and quake101.2 are in self-extracting LHA format; ports/archivers/lha will extract them. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
