audio permissions quandary, part 1
greg at romuald.net.eu.org
Wed Oct 10 14:37:56 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hi Frank and all.
Thanks for your suggestion. I actually e-mailed a friend of mine as
well with this, who isn't on this list, and here's what his
"Isn't maildrop marvellous?
The problem: maildrop doesn't set your supplemental group privileges
it changes its euid and egid according to the -d option.
Solutions I can think of:
1. Change maildrop so it does that, or ask someone else interested
to do it. I don't see where the problem is in doing that from a
point of view provided that the login program and set supplemental
together don't grant permission for access to hardware not appropriate
all users that use maildrop. For instance, a mailinglist manager
maildrop ought not get privileges to access pseudoterminals. I
think letting anyone not a real user use maildrop is a mistake anyway.
Use delivery to programs if you want a user to get mail for automated
processing and have the MTA either execute setuid binaries or switch
itself before executing the program.
2. As root, put a device node for your audio device into your home
directory, then arrange for only you to have read-write on the device.
Change ownership on the device to your unprivileged user. Make your
program use this device instead (specify the full path from maildrop).
3. Use a safe setuid root program to get at the device. Consider
for instance, which is quite hard to break. You won't, of course, be
to use a supplemental group to make beep work for a subset of users,
so you're still liable to be pissed off, but less so than with sound
4. Truely a last resort. Make sure your MTA switches user and sets
supplemental groups itself before running maildrop (necessitates
root privileges to play with more-or-less the whole time), without the
option. Sendmail runs this way by default if you don't set the
option on the daemon, although this botches local deliveries made with
unprivileged sendmail invokations done locally. If you won't/can't do
that, the next best thing is to write a small program, make it setuid
and readable only by the MTA, which takes a user and argv vector like
setuidgid. Such a program can be invoked by a nontrusted MTA, switch
then run your MDA with enough privileges to be useful. This is
essentially what I do: sendmail is untrusted, runs setuidgid with the
so that maildrop runs with users' privileges. Maildrop has that code
already, but this is more portable to other, potentially less
MDAs. The downside is that unless I'm being targetted by a
attack against sendmail, the attacker has a tool he can use to get
unlimited privileges. If he can make a run of setuidgid as root once
gaining the sendmail smmsp account, he can do bad things. Assumes, of
course, that the attacker knows this is necessary and that sendmail is
exploitable enough to grant such access.
- --- part 2 to follow ---
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
(authorization required, add me to your contacts list first)
Free domains: http://www.eu.org/ or mail dns-manager at EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Speakup