On Tue, Jun 30, 2009 at 12:18:44PM -0400, Theodore Tso wrote: > On Tue, Jun 30, 2009 at 04:18:54PM +0200, Karel Zak wrote: > > > > I think the scenario when the library is starting the daemon is > > very odd and should be reviewed ;-) > > > > Is there any Linux distribution with the setuid uuidd? Suse and > > Fedora/RHEL use init scripts and fork()+exec() in the library is > > waste of time. > > Debian and Ubuntu runs with the setuid uuidd, and starts it up from > the library. OK. > My understanding from why Red Hat (and perhaps SuSE too) runs it as a > daemon is that some security teams are on crack and somehow believe > that running a daemon as root 100% of the time (where a buffer overrun we are not on crack and we are not running the daemon as root, we use "uuidd" user and "uuidd" group, but without setuid. > > Try "strace -f uuidgen -t" .. so many syscalls and the final result > > is EACCES. > > Well, the EACCESS is from the fact that you're trying to ptrace a > setuid binary. I'm talking about non-setuid binary executed by non-root user. > > It would be nice to check access to /var/run/uuidd (or > > /var/lib/libuuid) before the exec() on all systems without setuid > > uuidd. > > We already try to connect to the uuidd daemon first, and then check > for the uuidd daemon's existence, before doing the fork/exec. So the > failure case you are worried about only occurs when (a) the uuidd > daemon is installed, but (b) the uuidd daemon is not running, and (c) > it is not installed setuid. yes, I care about (c) . > We could add some code that checks to see if daemon is setuid or > setgid, and if it is not, that the current user has access to > /var/run/libuuidd (I think a dynamic run-time test is suprior to a > static compile-time switch). Yes. > ---- but maybe it would be better to jump > through distros' stupid security bureacracy, on the grounds that a > setuid libuuid daemon is in fact much *safer* than keeping uuidd > running as root all the time? It's not about security... see Kay's response. Karel -- Karel Zak <kzak@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html