Re[2]: Unix Webcat Permission - Suggestions
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29363
interpreted = N
texte = The nobody user and nobody group are special in that they have no rights tologin, or to files other than their own. You can actually call them anythingyou want to; some Unix's use UID 99, some use UID 2**16 - 2 (65534). Some usenogroup instead of nobody so YMMV. I suppose the nobody group could havebeen named web or the admin could have created a group called web thatnobody and all web developers belong to.The SUID script is very easy to write, since it is literally the two lines Iwrote below in a file owned by root marked as world-executable and SUID. I wantto write a more userful Perl program to provide a way to upload files into astaging area and then move them into the executable location with the correctrights. The problem is that some versions of Unix have broken SUID support andyou need to do something special when you build Perl to emulate this. It isalso possible that a WebCat template could be written to manage this as well.What I was writing was how to set up WebCat under Unix in the most secure waypossible, assuming that the machine had other users who could access it. If youare the only user (apart from the Sys Admin), that has access to that area, youcan get away with more lenient security. I believe from my own testing,however, that the only way to be sure that WebCat has the proper rights to altera database file is to make sure that the file is owned by the nobody user. Ifyour database files are all read only, which mine are, you can get away withmaking the files readable by nobody and everything will work.John Peacock____________________Reply Separator____________________Subject: Re: Unix Webcat Permission - Suggestions Author:
(WebCatalog Talk)Date: 3/20/00 10:23 PMThanks for spending the time to write the below John.sorry for asking more newbie Q's but I am in a peculiar situation in that I amnot sysadmin, do not have root (I rely on ftp), know extremely little about unix,and mysys admin is so busy I rarely get his attention but he relies on me to tell himhowwebcat is supposed to be set up (since I am the only one doing serious webcatdevelopment on that Linux box).So you are saying below that not only the user but also the group should be settonobody? All I am wanting to be sure of is that webcat works and there is nochanceof webcat starting too many processes (sp?) (Sam Polk says if it gets over 3then thereis trouble) and getting multiple copies of the same db into its cache. So ifyou aresaying the group also has to be nobody then that eliminates the ability of ftpright? (I don't yet know my chances of getting such a SUID script.) Do youthinkthat if I make the owner of the databases that webcat edits nobody whileleaving thegroup set to web then I still run risk of the multiple copies of same db incacheproblem? Also I ask the same question with regard to the templates themselves -can Ileave the group as web and avoid the dupe db problem? If so, then what otherissuesmight still lurk that caused you to give your advice the way you did (below)?Thanks for your time-Johnjpeacock@univpress.com wrote:> Caveats: I do not work for SmithMicro and have picked up all of my Unix admin> skills from reading man pages and O'Reilly books (the traditional method). Iam> running Unix Apache Module version 3.06f (since I like to perform my own> installs, thanks). I tested this all with a clean install.>> Several users have asked for advice on permission settings and security. My> best advice is to make _all_ files owned by nobody, and _all_ directories> containing those files owned by nobody. This includes all webcatalog> files/directories as well as user templates and databases. This is thenormal> operating methodology for Unix daemons. You also should not give any rightsto> any other user. In other words:>> chown -R nobody:nobody * #recursively set owner> chmod -R go= * #set user/group rights to none>> This is not a security concern once you realize that the nobody user has no> rights to directly log in. Unix security hacks that prey on the nobody user> rely on tricking the O/S into upgrading nobody to root, or get some process> running as root to run bad code.>> If you need to be FTP'ing files up to the server, work with your Unix> administrator to create a SUID script that copies the files into the correct> location and sets their owner and rights to the above. If you follow theabove> suggestions, an ordinary user cannot even list the files in your WebCat> directories, let alone read them. The WebCat process will serve them up fine.> Ordinary users should never have direct access to WebCatalog served files> (IMHO). Once a fully multiuser WebCat daemon comes out (4.2?) that willchange,> but until then, anyone hosting WebCat will need to change rights/owners forall> files.>> I am thinking in the back of my head about a small WebCat application which> would facilitate managing multiple users/sites. Think about an admin database> with username, pathname source, and destination. One button update would copy> the source files to the destination, with the correct rights. I could evensee> a trigger to automate it (though I do not trust outside developers enough to> copy their templates onto my server without looking at them). Users wouldonly> need ordinary rights to their parallel directory structure and WebCat wouldonly> run the versions in the official directories.>> HTH>> John Peacock>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Associated Messages, from the most recent to the oldest:
|
- Re[2]: Unix Webcat Permission - Suggestions (jpeacock@univpress.com 2000)
|
The nobody user and nobody group are special in that they have no rights tologin, or to files other than their own. You can actually call them anythingyou want to; some Unix's use UID 99, some use UID 2**16 - 2 (65534). Some usenogroup instead of nobody so YMMV. I suppose the nobody group could havebeen named web or the admin could have created a group called web thatnobody and all web developers belong to.The SUID script is very easy to write, since it is literally the two lines Iwrote below in a file owned by root marked as world-executable and SUID. I wantto write a more userful Perl program to provide a way to upload files into astaging area and then move them into the executable location with the correctrights. The problem is that some versions of Unix have broken SUID support andyou need to do something special when you build Perl to emulate this. It isalso possible that a WebCat template could be written to manage this as well.What I was writing was how to set up WebCat under Unix in the most secure waypossible, assuming that the machine had other users who could access it. If youare the only user (apart from the Sys Admin), that has access to that area, youcan get away with more lenient security. I believe from my own testing,however, that the only way to be sure that WebCat has the proper rights to altera database file is to make sure that the file is owned by the nobody user. Ifyour database files are all read only, which mine are, you can get away withmaking the files readable by nobody and everything will work.John Peacock____________________Reply Separator____________________Subject: Re: Unix Webcat Permission - Suggestions Author: (WebCatalog Talk)Date: 3/20/00 10:23 PMThanks for spending the time to write the below John.sorry for asking more newbie Q's but I am in a peculiar situation in that I amnot sysadmin, do not have root (I rely on ftp), know extremely little about unix,and mysys admin is so busy I rarely get his attention but he relies on me to tell himhowwebcat is supposed to be set up (since I am the only one doing serious webcatdevelopment on that Linux box).So you are saying below that not only the user but also the group should be settonobody? All I am wanting to be sure of is that webcat works and there is nochanceof webcat starting too many processes (sp?) (Sam Polk says if it gets over 3then thereis trouble) and getting multiple copies of the same db into its cache. So ifyou aresaying the group also has to be nobody then that eliminates the ability of ftpright? (I don't yet know my chances of getting such a SUID script.) Do youthinkthat if I make the owner of the databases that webcat edits nobody whileleaving thegroup set to web then I still run risk of the multiple copies of same db incacheproblem? Also I ask the same question with regard to the templates themselves -can Ileave the group as web and avoid the dupe db problem? If so, then what otherissuesmight still lurk that caused you to give your advice the way you did (below)?Thanks for your time-Johnjpeacock@univpress.com wrote:> Caveats: I do not work for SmithMicro and have picked up all of my Unix admin> skills from reading man pages and O'Reilly books (the traditional method). Iam> running Unix Apache Module version 3.06f (since I like to perform my own> installs, thanks). I tested this all with a clean install.>> Several users have asked for advice on permission settings and security. My> best advice is to make _all_ files owned by nobody, and _all_ directories> containing those files owned by nobody. This includes all webcatalog> files/directories as well as user templates and databases. This is thenormal> operating methodology for Unix daemons. You also should not give any rightsto> any other user. In other words:>> chown -R nobody:nobody * #recursively set owner> chmod -R go= * #set user/group rights to none>> This is not a security concern once you realize that the nobody user has no> rights to directly log in. Unix security hacks that prey on the nobody user> rely on tricking the O/S into upgrading nobody to root, or get some process> running as root to run bad code.>> If you need to be FTP'ing files up to the server, work with your Unix> administrator to create a SUID script that copies the files into the correct> location and sets their owner and rights to the above. If you follow theabove> suggestions, an ordinary user cannot even list the files in your WebCat> directories, let alone read them. The WebCat process will serve them up fine.> Ordinary users should never have direct access to WebCatalog served files> (IMHO). Once a fully multiuser WebCat daemon comes out (4.2?) that willchange,> but until then, anyone hosting WebCat will need to change rights/owners forall> files.>> I am thinking in the back of my head about a small WebCat application which> would facilitate managing multiple users/sites. Think about an admin database> with username, pathname source, and destination. One button update would copy> the source files to the destination, with the correct rights. I could evensee> a trigger to automate it (though I do not trust outside developers enough to> copy their templates onto my server without looking at them). Users wouldonly> need ordinary rights to their parallel directory structure and WebCat wouldonly> run the versions in the official directories.>> HTH>> John Peacock>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
jpeacock@univpress.com
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
[OT] md5 or sha-1 on OSX (2007)
Replacefounditems (2003)
shipcost (1997)
Multiple prices (1997)
Error Log.db --however (1997)
Capturing the referring site (1999)
emails sent twice (2001)
[ListFiles] Within [LineItems] (2001)
expired beta (1997)
Help! WebCat2 bug (1997)
OT: 800x600 (2003)
Sorting Results (1999)
Re:Emailer and encryption (1997)
Search Summary (2005)
Paths, relative paths, webstar server setup andsecurity WebDNA-Talk@smithmicro.com (1997)
Cold Fusion Buster (1997)
WebCat2: Found Items syntax, etc. (1997)
Mac v. NT (1998)
web delivery (1997)
SKU (1997)