meta user
network profile
| bio | website | nicholaswilson.me.uk |
|---|---|---|
| location | Cambridge, United Kingdom | |
| age | ||
| visits | member for | 1 year, 2 months |
| seen | yesterday | |
| stats | profile views | 16 |
A recent maths Part III (masters) graduate, with interest in functional languages. Unix enthusiast. Has day job writing enterprisey C++ app.
|
1d |
comment |
What are the dangers of setting a high limit to max File Descriptors per process? Just to note, there can be a security impact too. Many servers are vulnerable to ACE if given more than FD_SETSIZE descriptors (usually 1024). A small sample of affected applications: securityfocus.com/archive/1/388201/30/0 So, only raise the soft limit higher than 1024 for specific applications you really trust, not system-wide. |
|
Feb 27 |
awarded | Yearling |
|
Feb 22 |
comment |
Drop Process Privileges Correct. initgroups, setgid, setuid (last!) is precisely the right paradigm on unix, and should always be followed. In addition, a responsible "droproot" function checks that its uid and gid really have been set, even if all three primary functions returned success. |
|
Feb 22 |
comment |
Drop Process Privileges @David Actually, setuid() does set real and saved userids; you may be thinking of seteuid(). Not all systems have setreuid(), so it can't be used quite everywhere. The exact semantics of setuid() are compliced, but if you have euid 0, you will be able to drop all traditional user-id privileges with setuid(). The biggest omission in this answer is that initgroups or setgroups must be called as well as setgid and setuid, and that more thorough assertions should be done at the end. |
|
Feb 22 |
comment |
Drop Process Privileges No, please don't run things using a shell simply to drop privileges. That leaves far too much in the control of an attacker, reading in various config files you don't want to be touching. |
|
Feb 22 |
comment |
Drop Process Privileges No. This is not good advice: calling setuid() alone is absolutely not enough. |
|
Feb 12 |
accepted | How do I write a login daemon? |
|
Feb 12 |
comment |
Is Red Hat Linux licensed You want CentOS, a beer-free build of the RedHat source. Only the source is open, not the installable builds. |
|
Jan 28 |
comment |
What are the dangers of setting a high limit to max File Descriptors per process? That sounds reasonable. We've run into this before on Solaris too; 256 is just too small as a default for modern systems. A non-forking server can easily peak at two hundred concurrent clients if the connections are being held open but idle for any length of time. |
|
Jan 23 |
revised |
How do I write a login daemon? clarified "login daemon" terminology, hopefully |
|
Jan 22 |
comment |
How do I write a login daemon? Well, telnetd is pretty historical, and some quite historic implementations do a lot of the legwork that's also in login(1). I'm trying to assemble here a list of all that. Some OpenBSM and Mach "ports" notes coming up... Nearly forgot them! |
|
Jan 22 |
revised |
How do I write a login daemon? link to github |
|
Jan 21 |
revised |
How do I write a login daemon? add information about PAM |
|
Jan 21 |
answered | How do I write a login daemon? |
|
Jan 21 |
accepted | Files bigger than max(off64_t) on Solaris, eg “/proc/../as” |
|
Jan 21 |
answered | Files bigger than max(off64_t) on Solaris, eg “/proc/../as” |
|
Jan 21 |
revised |
Files bigger than max(off64_t) on Solaris, eg “/proc/../as” retitled |
|
Jan 21 |
awarded | Citizen Patrol |
|
Jan 20 |
comment |
How do I write a login daemon? Is there a one-stop guide to all these already, or do we have to write one here? I have a good set of notes here already to kick off a wiki question if so, so don't get too busy answering straight away! |
|
Jan 20 |
asked | How do I write a login daemon? |
