[PATCH] Move setfsuid(geteuid()) in access daemon after unlink()

[Armin Größlinger]

Dear likwid developers,

please find attached a small patch which moves the setfsuid() (and umask())
call to reset the FSUID to the effective user ID just after the call to
unlink() on the communication socket.

On our cluster, we use the access daemon installed with "set user ID", but
we're not running the daemon with the effective user "root" but a special
unprivileged user "likwidd" which has access to the MSR registers, i.e., we have:

-rwsr-xr-x 1 likwidd root 24061 Nov 26 13:36 likwid-accessD

In this setup, the access daemon cannot unlink() the socket when the FSUID has
been reset to the effective user ID already. Hence, we suggest to move the
second call to setfsuid() just after the call to unlink().

The patch should apply against 3.1.3 and SVN trunk.

Thank you for creating likwid.

Best regards,
Armin

[Thomas Röhl]

Hi Armin,

thanks for your patch, I will apply it to the current SVN trunk. We finished the development in the 3.1 branch, there will be only 4.X versions with a more library-like approach.

Does your special unprivileged user is also capable of accessing the PCI monitoring devices? I would like to add such a setup to the wiki and documentation because many users do not like the root way.

Greetings,
Thomas

[Armin Größlinger]

Hi Thomas,

so far, our approach did not give our special unprivileged user access to the
PCI devices. But I took your question as a challenge and tried to implement
that now.

I'm attaching the udev rules file (40-likwid.rules) we use and the helper
script (chown-proc, called from the udev rules file) I wrote to derive the name
of the file in /proc/bus/pci corresponding to sysfs's devpath. These may need
some generalization for other system, e.g., I assumed that the devpath is
always of the form ".../0000:..." and that the driver for the PCI devices is
called "ivt_uncore". I'm not an expert at all for the PCI device handling, so
improvements to the script are welcome.

Best regards,
Armin

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "likwid-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to likwid-develop...@googlegroups.com
> <mailto:likwid-develop...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Röhl]

Hi Armin,

thanks for your research and scripts. I already forwarded your scripts to another university that has a similar problem. I linked them to this post, so they get all information we are writing here.

Your assumption of the PCI device paths starting with '0000:' is true in general. This is the PCI domain identifier, ACPI also calls it PCI segment. Since each system can host only 256 PCI buses, the domain construct was added to overcome this limitation. Comment for the Linux sources: 'A PCI domain is defined to be a set of PCI buses which share configuration space.' I haven't seen a system featuring multiple PCI domains, so this should work on almost all machines.

I have a question concerning the driver 'ivt_uncore'. Is this the driver that comes with the Intel VTune performance monitoring suite? The abbreviation 'ivt' could be Intel VTune, but a standard internet search discovered nothing.
On our compute nodes, this driver is not installed, hence I would like a more generic check for udev. I have to look up additional matches that can be used in udev rules. As far as I know Intel introduced a new PCI Class ID for the performance monitoring devices but I don't know whether this fits already for the SandyBridge PCI counters and whether udev supports matching for the PCI Class ID.

I will inform you about newer versions of your scripts. If you want I can also keep you up-to-date about suggestions and problems of other users.

Greetings,
Thomas