Hi I am running v3.2.0 in a Docker container and I wanted to do some logging with linelog so I set the filename parameter to "/dev/stdout". This gave me the error: Error: rlm_linelog: Failed to open /dev/stdout: Permission denied After googling this I understood that that I need to add the radius user to the tty group so did: usermod -a -G tty radius However this didn't help so I ran ls -l on /dev/stdout to see what the permissions were: lrwxrwxrwx 1 root root 15 Aug 4 14:05 /dev/stdout -> /proc/self/fd/1 Which links to: l-wx------ 1 root root 64 Aug 4 14:06 /proc/self/fd/1 -> pipe:[18026581]
From looking at this I worked out there was no tty group involved.
Then after researching this I tried adding "tty: true" to my docker-compose.yml file and then this gave me a device with write access from the tty group: lrwxrwxrwx 1 root root 15 Aug 4 14:45 /dev/stdout -> /proc/self/fd/1 lrwx------ 1 root root 64 Aug 4 14:45 /proc/self/fd/1 -> /dev/pts/0 crw--w---- 1 root tty 136, 0 Aug 4 2022 /dev/pts/0 However this did not help so I looked at the source code and noticed that FreeRADIUS is opening the file with read/write permissions whereas only write is available: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/main/exfile.... if (strncmp(filename, "/dev/", 5) == 0) { fd = open(filename, O_RDWR, permissions); So then I ran: chmod g+r /dev/pts/0 After this linelog was able to log to stdout. However with "tty: true" I am now getting some extra control characters in my logs such as "'#033#015". This is inconvenient but non critical. I would be grateful if anyone could advise or assist with a better solution. -- Benjamin Thompson
On Aug 4, 2022, at 4:14 AM, Benjamin Thompson <b.thompson@hydra-billing.com> wrote:
I am running v3.2.0 in a Docker container and I wanted to do some logging with linelog so I set the filename parameter to "/dev/stdout".
This gave me the error:
Error: rlm_linelog: Failed to open /dev/stdout: Permission denied
Yeah, that's a little weird.
However this did not help so I looked at the source code and noticed that FreeRADIUS is opening the file with read/write permissions whereas only write is available:
https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/main/exfile....
if (strncmp(filename, "/dev/", 5) == 0) { fd = open(filename, O_RDWR, permissions);
It's possible to add some checks there for permissions, and modify O_RDWR for that. I've pushed a fix. See commit 1abf810524 on GitHub. You should be able to add that to 3.2.0 without any issues.
So then I ran:
chmod g+r /dev/pts/0
After this linelog was able to log to stdout.
However with "tty: true" I am now getting some extra control characters in my logs such as "'#033#015". This is inconvenient but non critical.
Weird.
I would be grateful if anyone could advise or assist with a better solution.
See above. Alan DeKok.
Hi Alan Many thanks for your quick reply.
However this did not help so I looked at the source code and noticed that
FreeRADIUS is opening the file with read/write permissions whereas only write is available:
https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/main/exfile....
if (strncmp(filename, "/dev/", 5) == 0) { fd = open(filename, O_RDWR, permissions);
It's possible to add some checks there for permissions, and modify O_RDWR for that. I've pushed a fix.
See commit 1abf810524 on GitHub. You should be able to add that to 3.2.0 without any issues.
I tried the patch against 3.2.0 but it seems to be not detecting the permissions correctly and is still trying to open the device as read/write. I don't know why that is but I guess that it might be because it is not a real file and/or is behind several symlinks. Just as a test I added: if (strncmp(filename, "/dev/stdout", 11) == 0) { oflag = O_WRONLY; } This worked as expected. -- Benjamin Thompson
Hi Alan I tried the patch against 3.2.0 but it seems to be not detecting the
permissions correctly and is still trying to open the device as read/write.
I came back to this today and I realised that "permissions" is a config paramter. After setting it to 0020 the patch works correctly. Many Thanks -- Benjamin Thompson
participants (2)
-
Alan DeKok -
Benjamin Thompson