Home Section Blog
Blog
Unix permissions for web sites PDF Print E-mail
Technology
Written by Dennis Reinhardt   
Wednesday, 28 July 2010 09:07

There are many explanations of Unix file permissions on the web and I have come away slightly confused.  So, let me try a slightly different take.  I assume here that we are taking the view of a webmaster on a shared account setup.  Let's assume your account name is you and that your webserver runs under the account nobody.  There may be other account names in the system set up by the web host either as individual accounts or globally.

However, for simplicity, let's just work with the two accounts you and nobody.  For purposes of understanding, we will change the notation and presentation order from what you see in other presentations.

Any given file or directory, accounts can be in either of two roles: owner or other.  There is also a group role, which can largely be ignored in a web hosting context because all accounts are normally treated as independent.  If a file is created while you is logged in, you has the owner role and nobody has the other role.  If the file is created by running a web page, nobody has the owner role and you has the other role. 

So, merely logging in to your site via FTP does not necessarily give you owner access to all of "your" files.  It matters whether they were created via running one of your web pages or via your FTP login.  To further muddy the situation, some web pages supplied by your web host (e.g. cPanel) will create the files under you because web host software can have special hooks into privileged programs that can change owners, hooks not available to any account holder.

Before we can even think of working with a file, we need to consider the directory the file resides in or will reside in.  Each directory has an owner, either you or nobody.  The permission settings for the directory are

    4   L   directory may be listed

    2   C   files may be created or delete within the directory

    1   A   files may be accessed once created

The permissions are a numeric sum of the numbers listed.  It is typical for an owner to grant themselves full access (7) while restricting access for group and other.  Thus, you may see a permission value of 755 which is read, in digits, left to right as the owner, group, and other role permisisions, respectively. A more expanded and easier to comprehend notation is

    LCAL-AL-A

which is the same as 755.

However, "LCA" notation is not what you conventionally see because the Unix "ls" command reports back the settings for files and marks the line with an initial "d".  So, what ls reports back for a directory permission of 755 would look more like

    drwxr-xr-x

Here, we will continue with LCA notation because our goal here is understanding.

OK, now that we know about directory permissions, let's turn to file permissions.  Again, we have 3 settings with numeric values:

    4   R   file may be read

    2   W  file may be written to (contents replaced)

    1   X   file may be executed

The owner will not necessarily grant themselves full permission but will choose a value appropriate to the function of the file. An image or plain text file might have owner permisisions of 6 (RW-).  A PHP file might have owner permissions of 6 (RW-) or 7 (RWX) with the required difference a complicated function of whether the PHP file is run from the command line (or by crontab) and how the web server is implemented.  The point here is that owner permissions are not automatically defaulted to full permission.  Likewise, other role permissions are usually a subset of owner permissions in most cases by turn off the write permission (2 W).

From this exposition, it should be clear that a complete determination of permissions requires knowing your role for both the directory and file.  For example:

    dir=other  LCA  file=owner  RW-

Note that your roles for the directory and file can differ, as illustrated. However, the illustration grants full LCA permission to other so the ownership is moot.  The directory level permissions could prohibit access (1 A) for your role, making the RW settings somewhat moot.  You may also have permission to write a file but not delete it.

In all, there are 8 settings which apply to a file: 2 roles each for the directory and file, 3 permission settings for the directory, and 3 for the file.  In many discussions, this gets reduced to just the 3 permission settings for the file itself.  Such simplification is probably good enough for many of the situations you encounter.  However, without understanding that there are actually 8 settings given your role, you will be banging your head trying to understand why you cannot accomplish something.

Last Updated on Wednesday, 28 July 2010 13:23
 
Failed Products PDF Print E-mail
Marketing
Written by Dennis Reinhardt   
Tuesday, 29 June 2010 12:01

My first failed software product was in about 2003 or so.  I had been developing and maintaining my own compiler language for over a decade, since about 1985.  It had some unique feautures and I had made some money selling/using it pre-internet.  Now with the internet putting me before a world-wide audience, perhaps i could make a go of it. 

For about 2 years, I tried selling over the internet and had zero sales.  I ended up killing the product after attending a conference of about 300 software developers.  Among all the people I met, there was only one person who I thought was a suitable match for my language ... and he was selling his own language product!  I realized that the total world-wide market for this product could be me.

I pulled the product shortly after the conference and set about developing something new.  At the time, spam was emerging as a real bother and SpamAssasin was the premier solution.  At that time, I switched from using my proprietary compiler to using Python for most of my development.  I developed a SpamAssasin inspired solution but one not based on Bayesian inferencing, but, rather, on rules entered by the user as regular expressions. 

My product, SpamAI, enjoyed modest success but, unfortunately, many others thought anti-spam was an emerging field and the competition numbered in the hundreds.  After a good run of a few years, I pulled the product rather than go through the support costs of getting a new user running.  I still use it myself on a daily basis but have had the program off the market for years now.  Indeed, I let the domain registration lapse and the domain is in the hands of someone who is trying to sell it.

SpamAI is not a failed product.  It was successful but I pulled it off the market when the cost of supporting it exceeded any possible income from it.

For one product, DAIRGram Server, I tried changing my development methodology.  Rather than develop the specs myself, I would work hand-in-hand with a marketing partner who would guide the development.  Indeed, there were two partner, one after the other.  The partnerships did not last past the development stage but the product design benefited by by having several sets of eyes looking at the product over many months. 

Both partners had real needs but did not have the money to fund development.  It turned out that this turned out a good predictor for the market.  I had a few nibbles from people with needs and very little money.  Looking back, I don't think I could have predicted that.  One of the partnerships was absolutely dependent on both of us working as a team. The program was of no real value without him and his plans would never go anywhere without my software.

The DAIRGram Server product was meant to install on a user's server or could be run as a service by me.  I think that part of the problem with the product was, indeed, the service model.  I think the customer I was able to reach wanted desktop software they bought once.  They did not want to pay recurring charges for a service.

I did another server program, Syncation Server.  The idea was that it was a shared in-out board with (eventual) geo-location features.  There was simply no interest in a server program.  As part of the in-out board, I developed a telephone message taking component.  I have since extracted that component at TelephoneMessagePad.com and am selling it now as a client-side only component.  The server program failed but the extracted client program is doing fine.

The program which just failed is a website log file utility.  With millions of web sites and robotic visitors accounting for about half of all traffic, you would think there is a need to do a good job of separating which visitors are robotic from human?  So did I but many weeks of advertising have convinced me otherwise.

First, the number of searches for log analysis topics in a month on Google is in the few hundreds to a few thousand.  There is no tens or hundreds of searches per month term.  This volume is low for the markets I have competed in.  At the same time, the competition in this market is 10-15.  This is a saturated market and competition is high.

Many people satisfy their analysis needs by using Google Analytics.  A fraction now are using log analysis.  I know that before I brought my program to market.  Much of the reason I developed it was to meet my own internal needs.  So, I guessed that that market was not as large as the "millions of websites" might imply.

I was not prepared for having my ads ignored.  Even when my ad was delivered for relevant search terms, out of 1,500-2000 ad impressions spread over several weeks, I only got 3 click-throughs.  This is simply not high enough to run a business and Googles algorithms tend to drive up the cost of low click-though accounts and campaigns.  So, I stopped advertising the log analysis program.

I had plenty of advance warnings that there was low interest in log analysis.  What took me by surprise that I could not elicit interest even among those searching for log analysis topics.

I am working on a new product which early results say there is considerable interest.  That would be nice if that early promise delivers a success. 

Last Updated on Wednesday, 28 July 2010 10:44
 
Retiring shareware PDF Print E-mail
Marketing
Written by Dennis Reinhardt   
Wednesday, 16 June 2010 10:31

I have been a long time member of the Association of Shareware Professionals.  ... but, no more.  The association has decided that the "shareware" part of the name has outlived its usefulness.  The term has been in decline and has acquired a tawdry, undeserved reputation. 

The new name is Association of Shareware Professionals and here is a discussion/announcement

Last Updated on Wednesday, 28 July 2010 10:43
 
Retiring shareware PDF Print E-mail
Marketing
Written by Dennis Reinhardt   
Wednesday, 16 June 2010 10:31

I have been a long time member of the Association of Shareware Professionals.  ... but, no more.  The association has decided that the "shareware" part of the name has outlived its usefulness.  The term has been in decline and has acquired a tawdry, undeserved reputation. 

The new name is Association of Shareware Professionals and here is a discussion/announcement

Last Updated on Wednesday, 28 July 2010 10:44
 
What's not to like? PDF Print E-mail
Technology
Written by Dennis Reinhardt   
Wednesday, 02 June 2010 09:43

It was not too long ago that if you saw someone talking out loud to no one in particular, you avoided them for being a crazy person.  The likely explanation was they suffered from schizophrenia.  Nowadays, we don't call such people crazy.  We now call them cell phone users.

Likewise, people who used to worry about scrubbing every trace of their internet activity were likely criminals or crazy conspiracy theorists.  Yet again, technology seems to be nibbling away at the definition of crazy.

The latest crazy-bender is Facebook's new "like" button (1). 

This is a bit of JavaScript code which more than 50,000 publishers such as CNN, Yelp, and ESPN have adapted in a few weeks.

 If a Facebook user, you click the "Like" button on an external site and your preferences all over the web are now shareable.  This is a little creepy and perhaps can be sorted out with the Facebook privacy controls du jour, whatever they happen to be now.

 ... but suppose you never signed up for Facebook.  Tough, your visit to the site is still logged by Facebook's computers.  The "Like" button is actually JavaScript running in an iframe.  You don't have to click on the button for Facebook to know that you visited a site.  Just visiting the page is enough to trigger the access to Facebook computers. 

Accepting a cookie makes it easier for Facebook to correlate what "Like" sites you visit.  ... but it is not required as IP address, browser agent stings, and other "fingerprints" available to an iframe JavaScript can do a perhaps an effective job of tracking you individually or a small subset(2). 

Perhaps there is a FireFox extension for that or an IE setting to not access Facebook.  Anyone have a recommendation?

Are we entering an era where wearing a tin foil hat is the new sanity?

references

(1) http://www.cnn.com/2010/TECH/social.media/06/02/cnet.facebook.privacy.like/index.html?hpt=Sbin

 (2) https://panopticlick.eff.org/browser-uniqueness.pdf  94.2% of browsers were unique in survey with 18.1 bits of entropy. 

Last Updated on Wednesday, 28 July 2010 10:42
 
«StartPrev1234567NextEnd»

Page 1 of 7
Copyright © 2010 TextToolKit. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.