[cap-talk] Don't put capabilities in argv?
mrs at mythic-beasts.com
Sun Jul 13 08:35:13 CDT 2008
"Dean Tribble" <tribble at e-dean.com> wrote:
> On Sat, Jul 12, 2008 at 5:14 PM, Kevin Reid <kpreid at mac.com> wrote:
> > On Jul 12, 2008, at 17:43, Kevin Reid wrote:
> >> AFAIK, typical unix systems reveal command-line arguments of all
> >> processes to all users.
> > * The simplest safe-by-default mechanism I can think of is to read the
> > capability from a file whose name is passed on the command line.
> I was also going to suggest that (since it's what CapDesk does).
> Programs don't pass capabilities this way; they use some other
> architecture, but they store them and make them available and/or
> persistent for users this way.
That's similar to how X works for passing MIT-MAGIC-COOKIEs, which are
a kind of password. The cookies are stored in the user's Xauthority
file, which the X client finds through a combination of the XAUTHORITY
and HOME environment variables. The client takes the display address
and number from DISPLAY and looks that up in the Xauthority file.
These settings have a wonderful way of getting out of sync:
If you sudo to another user it may or may not change HOME (depending
on whether you use "-H"), which may or may not affect the Xauthority
filename that the X client uses (depending on whether XAUTHORITY is
set), and the X client may or may not be able to read the Xauthority
file (depending on whether you sudo'd to root or to another user).
Whether XAUTHORITY is set depends on whether you're logged in normally
(which sets XAUTHORITY) or via SSH (in which case XAUTHORITY is not
To add to the confusion, xauth and xlib use slightly different rules
for looking up DISPLAY names in the Xauthority file, so if you try to
copy an Xauthority cookie from one file to another using xauth, it
will sometimes copy the wrong one or copy nothing at all.
Also, the Xauthority file will get cluttered up with old entries that
you don't need any more, but if you delete the entry that you do need,
X clients will mysteriously fail to start -- without any error
messages, if you start them from a GUI.
D-Bus has a similar scheme where DBUS_SESSION_BUS_ADDRESS designates
the bus to use, but the authorization password/cookie is stored in
All of this hassle because environment variables are not private, and
for whatever reason no-one has got Unix kernels changed to make them
More information about the cap-talk