Hi Igor,
I think you are wrong.
I wrote this simple program that does what I suggested:
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char** argv){
uid_t low_uid = 1000;
uid_t high_uid = getuid();
seteuid(low_uid); // drop privilege
const char* fileName="test.txt";
FILE* file = fopen(fileName, "w");
if(file == NULL){
printf("File doesn't exist or you don't have the right to write it\n");
exit(1);
}
seteuid(high_uid); // regain privilege
chown(fileName, high_uid, high_uid);
fclose(file);
}
It drops temporarily root privileges and then gets them back.
This is its output:
$ ls -l test.txt
-rw-rw-r-- 1 slv slv 0 2011-11-24 19:17 test.txt
$ sudo ./uid //this is what the program above is compiled to
$ ls -l test.txt
-rw-rw-r-- 1 root root 0 2011-11-24 19:17 test.txt
$ ./uid
File doesn't exist or you don't have the right to write it
$ ls -l test.txt
-rw-rw-r-- 1 root root 0 2011-11-24 19:17 test.txt
Best regards,
Silviu
2011/11/24 Igor Galić <i.ga...@brainsware.org>
>
>
> ----- Original Message -----
> > > <DevilsAdvocate>
> > > What would it do when the file already exists and is owned by root?
> > > :)
> > > </DevilsAdvocate>
> > >
> > > It is hard to distinguish between "file owned by root, but we
> > > should
> > > append to it" and "file owned by root and the admin made a mistake
> > > in
> > > the conf file". The former is the usual case when starting a server
> > > with pre-existing log files, the latter is the case you are trying
> > > to
> > > avoid.
> > >
> > True. However, assuming that when Apache terminates, the owner of the
> > error log is set to be ${APACHE_RUN_USER}, then the problem of not
> > being able to access the file manifests only on the first run.
> > <SillyIdea>
> > Dear httpd admin, the ${ErrorLog} file can be opened only by root.
> > Wanna continue?
> > If yes, raise privileges this time only. There's not going to be a
> > next time.
>
> To repeat this again, just in case:
>
> Privileges can only ever be *dropped*
> Privileges can *never* be raised. This is by design.
>
> > </SillyIdea>
> >
> > All in all, I see your point. It's more of a maintenance issue.
> >
> > Thanks for the answers,
> > Silviu
> > > Cheers
> > >
> > > Tom
> > >
> > > ---------------------------------------------------------------------
> > > The official User-To-User support forum of the Apache HTTP Server
> > > Project.
> > > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > > " from the digest: users-digest-unsubscr...@httpd.apache.org
> > > For additional commands, e-mail: users-h...@httpd.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > The official User-To-User support forum of the Apache HTTP Server
> > Project.
> > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > " from the digest: users-digest-unsubscr...@httpd.apache.org
> > For additional commands, e-mail: users-h...@httpd.apache.org
> >
> >
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.ga...@brainsware.org
> URL: http://brainsware.org/
> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> " from the digest: users-digest-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
