suid bit on directories
Hello!
I am new on this list and thoroughly searched the FAQ, the archives and the web for this question, but couldn't find anything.
We wondererd why setting the guid bit on a directory makes all new files owned by the group of the directory, but this does not work for the suid bit, making new files owned by the owner of the directory.
It would be a good solution to make files created by Apaches mod_php in safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but the Owner of the directory.
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
It seems, this has to be patched for each file system separately, right? For example in linux/fs/ext2/ialloc.c.
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
Thanks
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Quoted 5 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
I guess it is considered a security hole if a user can create files not belonging to him.
Quoted 1 line
Actually, the suid bit on directories works at least under FreeBSD. Is
Not under 4.x (nor OpenBSD 2.9); or did I do anything wrong?
krakatoa ~ % uname -a
FreeBSD krakatoa.tectonics 4.5-STABLE FreeBSD 4.5-STABLE #13: Thu Mar 28 01:12:06 CET 2002 [email protected]:/local/usr/obj/usr/src/sys/KRAKATOA i386
krakatoa ~ % whoami
ware
krakatoa ~ % cd /tmp
krakatoa /tmp % mkdir xx krakatoa /tmp % sudo chown root.bin xx krakatoa /tmp % sudo chmod 6777 xx krakatoa /tmp % touch xx/yy krakatoa /tmp % ls -la xx
total 4
drwsrwsrwx 2 root bin 512 May 18 10:47 . drwxrwxrwt 20 root wheel 3072 May 18 10:47 .. -rw-r--r-- 1 ware bin 0 May 18 10:47 yy
krakatoa /tmp %
Cheers, Cedric Ware.
Hi Cedric,
Quoted 7 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
I guess it is considered a security hole if a user can create files not belonging to him.
where is it so much different from the guid flat on directories? That way too, you could get rights of a group of which you are not a member. As far as I can see, all what has to be prevented, is to create files with suid flag set within such a folder - not even for a microsecond (race-condition). Or do I miss something? Other issues are quota, but this problem already exists with guid bit for directories. And in my case (mod_php), it is even worse the way it is.
Quoted 3 lines
Quoted 1 line
Actually, the suid bit on directories works at least under FreeBSD. Is
Not under 4.x (nor OpenBSD 2.9); or did I do anything wrong?
OpenBSD is extremely carefully about security issues. Thus, it might not work at all in OpenBSD. But it works under FreeBSD (as an option which has to be compiled into the kernel). This is exactly what I would like to have for Linux.
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Quoted 7 lines · Michael Hoennig
Hi Cedric,
Quoted 5 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
Quoted 5 lines
Quoted 2 lines
I guess it is considered a security hole if a user can create files not belonging to him.
where is it so much different from the guid flat on directories? That way too, you could get rights of a group of which you are not a member. As
You don't get the rights of the group. This only allows the file/directory you could have created anyway to be created with the gid of the parent. And you still are the owner so it can be seen who is responsible for it existing.
The only possible way non-members could do this would be if the directory has dangerous^Wrisky permissions allowing non-group members to write in it.
I use sgid directories frequently. Usually with user-private-groups and umask of 002. It keeps lusers from misusing chmod.
Quoted 2 lines
far as I can see, all what has to be prevented, is to create files with suid flag set within such a folder - not even for a microsecond
_Please_ don't describe it this way. We don't want any files any time to be created with suid flag set automatically. Describe it as "the suid flag set _on_ the directory" or "suid directory", etc.
Quoted 3 lines
(race-condition). Or do I miss something? Other issues are quota, but this problem already exists with guid bit for directories. And in my case (
mod_php), it is even worse the way it is.
Group quotas are used even less than user quotas so i don't consider them much of an issue (someone else probably does). What i do consider an issue is user accountability. There are reasons besides quota only root can chown.
You haven't articulated how doing this would be of benefit to anyone. Leaving that aside you could work up a patch to allow this behaviour.
Features would be:
1 a non-default mount option.
2 either incompatible with quota or throwing up
warnings if quota is enabled.
3 ineffective if the directory is also sticky.
Personally i don't care for the idea but, hey, you can try. As long as it doesn't become a default it won't affect me.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
Michael Hoennig <[email protected]>:
Quoted 9 lines
Hello!
I am new on this list and thoroughly searched the FAQ, the archives and the web for this question, but couldn't find anything.
We wondererd why setting the guid bit on a directory makes all new files owned by the group of the directory, but this does not work for the suid bit, making new files owned by the owner of the directory.
The setgid bit on a directory is to support BSD activities. It used to be used for mail delivery.
Quoted 3 lines
It would be a good solution to make files created by Apaches
mod_phpin safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but the Owner of the directory.
No. You loose the fact that the file was NOT created by the user.
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
2. Consider what happens if a user creates a file in such a directory and it is executable. - since the file is fully owned by a different user, it appears to have been created by that user. What protection mask is on the file? Can the creator (not owner) make it setuid? (nasty worm propagation method)
Quoted 5 lines
It seems, this has to be patched for each file system separately, right? For example in
linux/fs/ext2/ialloc.c.Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Hi Jesse,
Quoted 2 lines
The setgid bit on a directory is to support BSD activities. It used to be used for mail delivery.
this is actually similar usage to my example:
Quoted 5 lines
Quoted 3 lines
It would be a good solution to make files created by Apaches
mod_phpin safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but the Owner of the directory.No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
Quoted 6 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory
and it is executable. - since the file is fully owned by a different
user, it appears to have been created by that user. What protection
mask is on the file? Can the creator (not owner) make it setuid?
(nasty worm propagation method)
Again: it depends on the usage. In my case it is the other way around. A use should know what he is doing if he is setting this flag on a directory. And making such files suid again, has to be prevented by the code - that I even mentioned in my first mail on this issue.
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
I only said, it works under FreeBSD, it is an option there.
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Michael Hoennig <[email protected]>:
Quoted 12 lines
Hi Jesse,
Quoted 2 lines
The setgid bit on a directory is to support BSD activities. It used to be used for mail delivery.
this is actually similar usage to my example:
Quoted 4 lines
Quoted 3 lines
It would be a good solution to make files created by Apaches
mod_phpin safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but the Owner of the directory.
Quoted 6 lines
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
You can't tell who the user is. ANY user would be able to do that.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
Quoted 10 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory
and it is executable. - since the file is fully owned by a different
user, it appears to have been created by that user. What protection
mask is on the file? Can the creator (not owner) make it setuid?
(nasty worm propagation method)Again: it depends on the usage. In my case it is the other way around. A use should know what he is doing if he is setting this flag on a directory. And making such files suid again, has to be prevented by the code - that I even mentioned in my first mail on this issue.
How are you going to control it?
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
I only said, it works under FreeBSD, it is an option there.
Then use FreeBSD.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Hi Jesse,
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
You can't tell who the user is. ANY user would be able to do that.
of course not, but many features have to be used carefully, like the suid bit on files too!
I don't want to make the bahaviour or a suid bit on directories the default! I just would like it as a mount option, or even something which you have to compile into the kernel.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
Why do you ignore my example? In my example the use who runs the webserver owns all the files, that is wrong. With the suid bit on directories, this could be fixed.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a
directory and it is executable. - since the file is fully owned by
a different user, it appears to have been created by that user.
What protection mask is on the file? Can the creator (not owner)
make it setuid?(nasty worm propagation method)
Quoted 6 lines
Quoted 4 lines
Again: it depends on the usage. In my case it is the other way around. A use should know what he is doing if he is setting this flag on a directory. And making such files suid again, has to be prevented by the code - that I even mentioned in my first mail on this issue.
How are you going to control it?
Only the owner of the directories can set this flag. There is nothing to control.
UNIX users are able to give rights to everybody to their files, right? How do you control that?
You don't! You just let it to the users to give access to there files to whomever you want. My case is similar.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
I only said, it works under FreeBSD, it is an option there.
Then use FreeBSD.
No comment.
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Quoted 3 lines · Michael Hoennig
Why do you ignore my example? In my example the use who runs the webserver owns all the files, that is wrong. With the suid bit on directories, this could be fixed.
CAP_FCHOWN would appear to accomplish what you need (with the bonus of already existing in modern linux kernels)... the webserver should be able to chown away a file if it's given this capability.
-dean
Quoted 9 lines · dean gaudet
Quoted 3 lines · Michael Hoennig
Why do you ignore my example? In my example the use who runs the webserver owns all the files, that is wrong. With the suid bit on directories, this could be fixed.
CAP_FCHOWNwould appear to accomplish what you need (with the bonus of already existing in modern linux kernels)... the webserver should be able to chown away a file if it's given this capability.
This is a useful point, but doesn't address the intent of the original proposal. The solution you propose gives VERY powerful capabilities to a process, and if I undestand how it works gives them in every directory.
By putting them on a single directory like setgid, you allow any tool to operate on files in the directory, given that the process has directory access to do so. Think "groupware" and people working on a project.
Both are useful, of course, but they are NOT alternative solutions to the same problem, but solutions to two problems.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Michael Hoennig <[email protected]>:
Quoted 9 lines
Hi Jesse,
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
Quoted 4 lines
Quoted 1 line
You can't tell who the user is. ANY user would be able to do that.
of course not, but many features have to be used carefully, like the suid bit on files too!
That CAN be audited. Putting a suid on a directory CAN'T.
Quoted 3 lines
I don't want to make the bahaviour or a suid bit on directories the default! I just would like it as a mount option, or even something which you have to compile into the kernel.
Once mounted/compiled in you have lost control.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
Quoted 8 lines
Quoted 4 lines
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
Why do you ignore my example? In my example the use who runs the webserver owns all the files, that is wrong. With the suid bit on directories, this could be fixed.
That is NOT wrong. The files belong to the server. Not a user. I've been running a server that way for years.
And ANY user can put files into YOUR directory. Even files you don't want there. AND you can't tell who did it.
Remember - with this facility any penetration of of a server suddenly becomes a penetration of every user with such a directory.
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a
directory and it is executable. - since the file is fully owned by
a different user, it appears to have been created by that user.
What protection mask is on the file? Can the creator (not owner)
make it setuid?(nasty worm propagation method)Again: it depends on the usage. In my case it is the other way around. A use should know what he is doing if he is setting this flag on a directory. And making such files suid again, has to be prevented by the code - that I even mentioned in my first mail on this issue.
Quoted 4 lines
Quoted 1 line
How are you going to control it?
Only the owner of the directories can set this flag. There is nothing to control.
Ah - so I can put files into your directory, and suddenly they are owned by you. Remember that the next time you are convicted of piracy with criminal data in your directory.... (DMCA remember - and saying "Those files are not mine" just doesn't cut it, when obviously they have your uid on them; the best you would work them down to is "contributing to piracy").
Also remember what happens when a hard link is created in the directory... The file changes ownership. That will then change the owner of ANY file on the filesystem. I believe this can happen with sgid directories too (which would be another reason that mail spool directories were supposed to be on their own file system).
Quoted 2 lines
UNIX users are able to give rights to everybody to their files, right? How do you control that?
MLS/compartmentalization. See SELinux. See mandatory access controls.
Also put users in filesystems where the parent directory only permits group access: mode 0550. No user outside the group will be able to access the files, even if the user does grant access. Details:
sample - mode 0550
|
users - mode 0555Only members of the group, or owners will be able to see files in the directory "users", even though the owner of that directory has granted world rx access.
Quoted 2 lines
You don't! You just let it to the users to give access to there files to whomever you want. My case is similar.
NOT the same situation. The OWNER of the file gives ACCESS to files. Not a user making their files owned by someone else (unless that user is root). Even giving someone else the ability to create files in your directory is dangerous, though possible. At least it is still possible to determine WHO put them there.
This was explicitly removed to prevent quota corruption - the history of chown originally allowed changing the ownership of a file to anyone in the system (when done, it did remove setuid from the file). This was removed under the "prevention of a denial of service" attack.
Quoted 10 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
I only said, it works under FreeBSD, it is an option there.
Then use FreeBSD.
No comment.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Hi Jesse,
Quoted 4 lines
Quoted 2 lines
of course not, but many features have to be used carefully, like the suid bit on files too!
That CAN be audited. Putting a suid on a directory CAN'T.
Of course it can. You can easily list all files with this flag set.
Quoted 5 lines
Quoted 3 lines
I don't want to make the bahaviour or a suid bit on directories the default! I just would like it as a mount option, or even something which you have to compile into the kernel.
Once mounted/compiled in you have lost control.
How do you come to that conclusion? Even if it were the case: I don't force you to use this mount option.
Quoted 6 lines
Quoted 3 lines
Why do you ignore my example? In my example the use who runs the webserver owns all the files, that is wrong. With the suid bit on directories, this could be fixed.
That is NOT wrong. The files belong to the server. Not a user. I've been running a server that way for years.
Files can only belong to users, not to server processes.
Quoted 2 lines
And ANY user can put files into YOUR directory. Even files you don't want there. AND you can't tell who did it.
Nope. Only httpd and the user who should onw the files (the User of the VirtualHost) can reach the directory in my case. Nobody else can even reach it.
Quoted 2 lines
Remember - with this facility any penetration of of a server suddenly becomes a penetration of every user with such a directory.
With the rights of wwwrun/httpd you can do more damange in this case than with the rights of one user. In this case that are special accounts for running CGIs etc.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
How are you going to control it?
Only the owner of the directories can set this flag. There is nothing to control.
Ah - so I can put files into your directory, and suddenly they are owned by you.
You would not even reach this directory. That is assured because it is child of a dir owned by me:httpd which is child of a directory owned by httpd:mygroup - in neither case rights for others.
Quoted 4 lines
Also remember what happens when a hard link is created in the directory... The file changes ownership. That will then change the owner of ANY file on the filesystem. I believe this can happen with sgid directories too
good point to pay attention to, but you are wrong
Quoted 4 lines
Quoted 2 lines
You don't! You just let it to the users to give access to there files to whomever you want. My case is similar.
NOT the same situation. The OWNER of the file gives ACCESS to files.
I coudl set up a cronjob which copies the files in the directories and deletes the originals. It's the same, just delayed.
Anyway, when I find time in the next weeks, I will try this patch and post it. I will do it as a mount option. Nobody is forced to use it ;-)
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Quoted 2 lines · Michael Hoennig
Anyway, when I find time in the next weeks, I will try this patch and post it. I will do it as a mount option. Nobody is forced to use it ;-)
If I might offer a suggestion, that requires a patched mount command, etc. I would offer as an alternative implementation which might be both easier to do and more useful in testing. Make the capability an option in the kernel, and then require that it be enabled in /proc/sys with default off. Think TCP_SYN_COOKIES or similar. That way you can have a single patch set for the kernel only, and no one can possibly "stumble on it" and complain. Also, you can disable without reboot or remount after testing.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Hi Bill,
Quoted 4 lines
Quoted 3 lines
Anyway, when I find time in the next weeks, I will try this patch and post it. I will do it as a mount option. Nobody is forced to use it ;-)
Quoted 8 lines
If I might offer a suggestion, that requires a patched mount command, etc. I would offer as an alternative implementation which might be both easier to do and more useful in testing. Make the capability an option in the kernel, and then require that it be enabled in
/proc/syswith default off. ThinkTCP_SYN_COOKIESor similar. That way you can have a single patch set for the kernel only, and no one can possibly "stumble on it" and complain. Also, you can disable without reboot or remount after testing.
Good idea; I will consider it.
Michael
Signature · 3 lines
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426 http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht
Quoted 2 lines · Jesse Pollard
That is NOT wrong. The files belong to the server. Not a user. I've been running a server that way for years.
This is insecure.
A user has a defined security context. If the user can create code that is then executed in a different security context (user httpd/nobody), then you've got a potential problem. If you have multiple users who can create code that executes in the *same* security context, you have a recipe for disaster.
user1 can write a web app the delete/modifies the web app, or web app created files of user2.
Dax Kelson
Guru Labs
In article <[email protected]>,
Quoted 2 lines · Jesse Pollard
And ANY user can put files into YOUR directory. Even files you don't want there. AND you can't tell who did it.
A setuid bit on a directory doesn't mean it syddenly has rwxrwxrwx permissions. You still need permission to create the file as usual. Try playing with a setgid directory one day. It behaves the same.
Quoted 8 lines
Quoted 2 lines
Only the owner of the directories can set this flag. There is nothing to control.
Ah - so I can put files into your directory, and suddenly they are owned by you. Remember that the next time you are convicted of piracy with criminal data in your directory.... (DMCA remember - and saying "Those files are not mine" just doesn't cut it, when obviously they have your uid on them; the best you would work them down to is "contributing to piracy").
It would be stupid to have a setuid directory world writable. You'd probably make it group writab;e. Then only people in that group have access to create files, so the files aren't anonymous - they were created by someone in that group.
Quoted 2 lines
Also remember what happens when a hard link is created in the directory... The file changes ownership.
Adding an extra directory entry for a file doesn't change the inode (well, the link count is bumped up by one) in any way.
Mike.
Signature · 2 lines
"Insanity -- a perfectly rational adjustment to an insane world." - R.D. Lang
Quoted 10 lines · Jesse Pollard
Michael Hoennig <[email protected]>:
Quoted 3 lines
Quoted 1 line
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
I won't repeat my previous, but obviously the owner of the file is
charged, and (b) if you care who put it there don't have a directory like that. If you are a control freak you don't create the directory in the first place. The behaviour is a feature not a problem.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory
and it is executable. - since the file is fully owned by a different
user, it appears to have been created by that user. What protection
mask is on the file? Can the creator (not owner) make it setuid?
(nasty worm propagation method)
Quoted 6 lines
Quoted 4 lines
Again: it depends on the usage. In my case it is the other way around. A use should know what he is doing if he is setting this flag on a directory. And making such files suid again, has to be prevented by the code - that I even mentioned in my first mail on this issue.
How are you going to control it?
The code is already in place to remove the setuid bit when changing
the owner of a file. I don't see more than an AND on the permissions in creat() to provide this protection as the owner is changed.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
I only said, it works under FreeBSD, it is an option there.
Then use FreeBSD.
If developers had taken that approach to suggestions for enhancements in
network code people would, and Linux would be saddled with the 1.x network code (shudder). Ditto journaling, bitmapped filesystems, etc. All started from features in other operating systems. To reverse your idea, if you don't want progress stay with 2.2.xx and don't read a DEVELOPMENT list.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc "He stood across the path of progress, loudly crying HALT!"
Quoted 11 lines · Jesse Pollard
Michael Hoennig <[email protected]>:
Quoted 8 lines
[Jesse Pollard???]
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
You can't tell who the user is. ANY user would be able to do that.
If you have a setuid directory, then you accept responsibility for anything that other people place in that directory.
If you are the admin, you hold the owner of a setuid directory responsible for everything that gets put in it.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
1. users will steal/bypass quota controls
Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
Duh, this is a web server.
If you really don't understand, then read up on dynamic web stuff and web authentication:
cgi-bin, PHP, WebDAV, Java servlets, SSL...
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory and it is executable. - since the file is fully owned by a different user, it appears to have been created by that user. What protection mask is on the file? Can the creator (not owner) make it setuid? (nasty worm propagation method)
Oh please. Do you know that Linux supports a setgid bit on directories? Well, it does, just the same as SysV. Go ahead, try to get setgid for a group you aren't in. Linux will even take away your setuid bit for trying.
"Albert D. Cahalan" <[email protected]>:
Quoted 26 lines
Quoted 11 lines · Jesse Pollard
Michael Hoennig <[email protected]>:
Quoted 8 lines
[Jesse Pollard???]
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
You can't tell who the user is. ANY user would be able to do that.
If you have a setuid directory, then you accept responsibility for anything that other people place in that directory.
If you are the admin, you hold the owner of a setuid directory responsible for everything that gets put in it.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group or user. Normally it is based on user. Once the uid is set, then the quotas start being deducted. If the the user procedes to store 10 G of music files, who is charged? And how do you know who put them there.
Duh, this is a web server.
A web server is just a user.
Quoted 4 lines
If you really don't understand, then read up on dynamic web stuff and web authentication:
cgi-bin, PHP, WebDAV, Java servlets, SSL...
so? And each has been penetrated before.
This is no improvement. It is a step backward to when chown would give a file to any user. It was used several times to attack quotas, several times to hack systems.
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory and it is executable. - since the file is fully owned by a different user, it appears to have been created by that user. What protection mask is on the file? Can the creator (not owner) make it setuid? (nasty worm propagation method)
Oh please. Do you know that Linux supports a setgid bit on directories? Well, it does, just the same as SysV. Go ahead, try to get setgid for a group you aren't in. Linux will even take away your setuid bit for trying.
Yup. and it depends on where the setuid is as to whether it is taken away.
It would be much better to get ACLs to support this, which I think all of the implementations of ACLs do.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Quoted 8 lines · Jesse Pollard
Quoted 6 lines
Quoted 1 line
No. You loose the fact that the file was NOT created by the user.
the user in my example above would be wwwrun or httpd - and that does not make any sense at all! It would make much more sense if the new files belonged to the owner of the directory, who is the one who owns the virtual host.
You can't tell who the user is. ANY user would be able to do that.
Bzzzt. Only if the permissions permitted it.
Example 1:
/home/bob/public_html
public_html is user/group bob/httpd
the perms are 2770
============================
Example 2:
All users on the system have a primary or secondary group "users"
/home/bob user/group bob/users
perms are 701
This explictly denies "users", yet allows Apache in (since it is running as httpd).
Quoted 7 lines · Dax Kelson
Example 1:
/home/bob/public_html
public_htmlis user/group bob/httpdthe perms are 2770
I meant 4770 since we are discussing a hypothetical SUID directory.
Quoted 11 lines · Dax Kelson
Quoted 7 lines · Dax Kelson
Example 1:
/home/bob/public_html
public_htmlis user/group bob/httpdthe perms are 2770
I meant 4770 since we are discussing a hypothetical SUID directory.
I would expect public_html to be 4775 or 4771 if it's to be any use at all. Otherwise why have it?
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 14 lines · Bill Davidsen
Quoted 10 lines · Dax Kelson
Quoted 6 lines · Dax Kelson
Example 1:
/home/bob/public_html
public_htmlis user/group bob/httpd
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
the perms are 2770
I meant 4770 since we are discussing a hypothetical SUID directory.
I would expect
public_htmlto be 4775 or 4771 if it's to be any use at all. Otherwise why have it?
Yes, it would have to have httpd group ownership or it would be totally inaccessible - and it would be difficult for a non-root user to assign such grp ownership....
Joe
Quoted 6 lines · Jesse Pollard
Michael Hoennig <[email protected]>:
Quoted 3 lines
We wondererd why setting the guid bit on a directory makes all new files owned by the group of the directory, but this does not work for the suid bit, making new files owned by the owner of the directory.
Quoted 8 lines
The setgid bit on a directory is to support BSD activities. It used to be used for mail delivery.
Quoted 3 lines
It would be a good solution to make files created by Apaches
mod_phpin safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but the Owner of the directory.No. You loose the fact that the file was NOT created by the user.
What's your point here? Obviously the owner of the directory wants it
that way. Linux is about choices, Windows is about "we know best." Like creating a set-uid file it can be misused, but I ran mail on SCO for years set-uid mail (not root) as an access control.
Quoted 6 lines
Quoted 4 lines
I do not even see a security hole if nobody other than the user itself and httpd/web can reach this area in the file system, anyway. And it is still the users decision that files in this (his) directory should belong to him.
1. users will steal/bypass quota controls
How? The quota should work just as well, the code doesn't seem to care
how the owner was set, just who owns the file. I can think of several groupware applications for using a group to get write, and having the files owned by the uid of the application. "chmod 4775 shared_dir" comes to mind. Yes, it has a sharp edge, you could do something dumb. See above on o/s philosophy. And this may result in quota being correctly applied to the filespace of a project rather than on individuals who may be creating files in many places, some not releated to a given project.
Quoted 5 lines
2. Consider what happens if a user creates a file in such a directory and it is executable. - since the file is fully owned by a different user, it appears to have been created by that user. What protection mask is on the file? Can the creator (not owner) make it setuid? (nasty worm propagation method)
Clearly the owner is the owner, and the creator is just another user
after the file is created.
Quoted 4 lines
Quoted 2 lines
Actually, the suid bit on directories works at least under FreeBSD. Is there any reason, why it does not work under Linux?
I don't believe it is in the POSIX definition.
Neither is clone() and a lot of other stuff. I would say that if POSIX
mandates behaviour or features Linux should follow, if POSIX forbids it should be forbidden, and everything else is up for discussion. (for discussion read SuS for POSIX if you care).
I think the feature is a config option at kernel build time in BSD, but
I didn't go refresh my dusty memory.
Useful tools are often dangerous, this would seem to be one of those
cases. Linux already has more cutting edges than a Swiss Army Knife, and I think you have enumerated the dangers in this features. I don't see any which are subtle.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.