#325 Add support for file ownership in FileAppender

[Alexis Wilke]

I am wondering whether you would be interested by a patch that would add file ownership information in the properties of the FileAppender configuration file.

There is an example of what I would add to the properties for this feature to work:

log4cplus.appender.log_file.File=/var/log/snapwebsites/snapserver.log
log4cplus.appender.log_file.Owner=snapwebsites
log4cplus.appender.log_file.Group=snapwebsites
log4cplus.appender.log_file.Mode=640

That would mean that the file /var/log/snapwebsites/snapserver.log would be given "snapwebsites" as the name of the owner and group and then the mode would be changed to 640 (i.e. read/write by snapwebsites, read-only as people part of the group snapwebsites, and no access to others.)

Since I use many servers, many sharing the same log files, the RollingFileAppender does not work right (it creates many problems.) So instead of using that, I decided to use logrotate and that means I have to have the correct ownership on files for the rotations to happen securely.

If you think that would be great, I'll look into creating a version from the latest 1.2.x and add those 3 properties. As far as I know, that would also work under MS-Windows, although I have no idea how to properly implement the Owner/Group information. The Mode is also limited to something like 2 bits, so it would pretty much be just a Unix implementation that could be extended by someone who wants such a feature for Windows.

[Václav Haisman]

That would mean that the file /var/log/snapwebsites/snapserver.log would be given "snapwebsites" as the name of the owner and group and then the mode would be changed to 640 (i.e. read/write by snapwebsites, read-only as people part of the group snapwebsites, and no access to others.)

First, I am not saying will reject such a patch outright. But, I thought about ownerships and access bits before and I thought that this is handled basically by running your application under the right user and having some appropriate umask set. One of the problems with this is that log4cplus is using C++ IO streams and cannot influence the access rights and ownerhip on open. It would have to do that after the file is open, which leaves a small window open when they are not right.

[Alexis Wilke]

Yes. I agree with your statement, unfortunately, my server does things this way:

1. Start server
2. Create logger so if anything is wrong it can get logged
3. Get information about TCP/IP
4. Open a socket, the port may be <= 1024 so server has to be root
5. Call listen()
6. Now I can drop down to snapwebsites as the UID of the process
7. Once a day or so, reopen the log file which may have been rotated (my process gets a signal when that happens)

My main problem is that I use properties, so I have no clue whether the user defined a filename, a simpleserver, uses syslog... so on step (2) I have no clue whether I have to fix file information or not and I am root because I may be opening a socket that requires my application to be root.

So I was thinking that the best solution would be to have it directly in the FileAppender. That being said, I could also offer a contrib UnixFileAppender that you just put in a contrib folder and that way the main FileAppender remains untouched. (although you don't yet have a contrib folder...)

[Alexis Wilke]

It would have to do that after the file is open, which leaves a small window open when they are not right.

I guess another solution is for me to drop to the correct user, open the log files, then become root again when I create the socket() / listen() and finally drop back to the correct user for good. That may be less work actually. 8-)

[Václav Haisman]

Well, I have done some small reasearch and I think should be able to do what you want with some effort and limitted portability. GCC offers __gnu_cxx::stdio_filebuf<_CharT, _Traits>. It would allow us to open the file with the appropriate modes, etc., using POSIX API and then create a C++ IO streambuf. I do not think there is anything comparable for Clang/libc++.

[Václav Haisman]

Well, universally, there is Boost's File Descriptor Devices. But that would have to be strictly optional.

[Alexis Wilke]

Hmmm... I don't think using g++ special classes would be a good idea.

Otherwise, I see that you have some sort of references to boost, but you do not seem to be using it at all. So I don't know that you would want to add such a dependency.

The chmod() function, though, is available on Unix and MS-Windows. Microsoft adds an underscore so we still need a small amount of #ifdef/#endif somewhere. Also their chmod() is limited compared to Unix. Instead we could use their other API that allows for things similar to Linux ACL. I personally do not know anything about these, but having the function started could make some people come forward and actually write a full implementation.

However, the chown() function available under Unix is not available as is under MS-Windows. I do not know the API, but there is a way to setup the user name and group of a file under MS-Windows. So what I would propose is that we write two log4cplus internal functions that can be used from anywhere in log4cplus to change permissions and ownership, and within those functions make the necessary so they work as expected on such and such system (as far as I know there would be a need for only two flavors: Unix and MS-Windows).