[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Notice: in file [ROOT]/includes/session.php on line 2208: Array to string conversion
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Poco Forums • View topic - Problem running in Limited User mode (XP Pro)

Problem running in Limited User mode (XP Pro)

Help and advice on using PocoMail

Moderators: Eric, Tomas, robin

Problem running in Limited User mode (XP Pro)

Postby waratel » Wed Jul 28, 2004 4:30 am

I have encountered a wierd problem since migrating my Pocomail (3.03 Build 1740) to a Limited User account under Win XP Pro. Basically emails with attachments now display the original body of the email as "Attached files inline display", many of these use the file att0.txt (which contains irrelevant junk), thus preventing me from seeing the actual content of the email.

If I start Pocomail under my Admin account, or upgrade the Limited account back to Admin, then the emails are displayed correctly.

Unfortunately the old posts on the forum are gone (:evil:) , but there was one which suggested use of the CACLS command to give full access to Pocomail folders for Limited Users. I have carried out this procedure, but still have the problem described. Like some others here, I place all my Pocomail paths in Shared Documents folders, so access to actual email folders should not be inhibited by Limited User privileges.

This problem is looking like either a registry access denial or Windows folder access denial.

Any suggestions ???

Bill
waratel
Drop-in Visitor
 
Posts: 11
Joined: Wed Jul 28, 2004 4:11 am
Location: Melbourne, Australia

Postby Pete » Wed Jul 28, 2004 10:22 am

Hi Bill, this sounds similar to a problem that Gert (another forum poster) is having with deleting attachments from inside the Shared Documents folder. One possible explanation is that there is more than one WinXP user trying to use files with identical filenames (e.g. att0.txt) in PocoMail's Attach folder at the same time.

Have you tried completely logging out all of the other WinXP users except for a single "Limited User" to see if the problem happens in this case? The answer to this might reveal a problem with one user's instance of PocoMail locking a file such as att0.txt while another user is trying to read/change/delete the file (unsuccessfully).
Pete
 

Postby waratel » Wed Jul 28, 2004 11:37 am

Pete, Yes does seem a little similar, and I did see Gert's post before I wrote mine. But there are key differences. I am not actually trying to delete an attachment. The spurious attachment att0.txt or att0.htm is appearing inline in place of body of most emails I have previously sent which contained attachments.

Most incoming emails with attachments or HTML formatted emails are displayed with both plain text and attached content in "Attached files inline display" mode. Plain text emails with no embedded content, both in and out, display as expected.

Re my Admin account; yes I am completely logged out of that and symptoms are as described. I am not trying to run two instances of Pocomail.

By changing my Limited User account back to Administrator type this symptoms go away, thus proving that the actual email content is intact. Compressing mailboxes does not clear the problem.

This is starting to look like a bug to me.

Bill
waratel
Drop-in Visitor
 
Posts: 11
Joined: Wed Jul 28, 2004 4:11 am
Location: Melbourne, Australia

Postby waratel » Wed Jul 28, 2004 1:52 pm

Further info - if I run Pocomail within my Limited User account, but with credentials of administrator, then the symptoms disappear*, but I would prefer to have a proper solution, as this can have implications by limiting access to files outside Pocomail.

* except some inbound emails which are text-only are still displaying as "attached inline file display" mode. That is the entire content is treated as an attachment when I don't think it is.

Bill
waratel
Drop-in Visitor
 
Posts: 11
Joined: Wed Jul 28, 2004 4:11 am
Location: Melbourne, Australia

Postby gert » Wed Jul 28, 2004 5:25 pm

The files/folders are probably 'owned' by the user Administrator (or another user).

Login to XP using that account (or an Admin account), right click the PocoMail folder, select properties -> security. Click Add to add a user (the user you want to use), or select the user if it is already in the list.
Now, make sure this user has "Full Control" checked.

When asked, tell XP to apply this to all files/folders below the PocoMail directory.

Gert
gert
Poco Tourist
 
Posts: 43
Joined: Sun Jul 25, 2004 4:20 pm

Postby Pete » Wed Jul 28, 2004 5:42 pm

Gert, as I understand things, if he installed PocoMail and all of its data folders under the "Shared Documents" folder, then all users should automatically have read/write access to all of the files and folders. So I agree with you, but I don't think that he should have to explicitly grant any file permissions.

Bill, I don't think that I can offer much help with this, but I do have one question:

When you say that the problem goes away when you login as an admin, (1) do you mean that the admin can see things in the Preview Pane that the Limited User can not see when looking at the same, previously downloaded messages? Or (2) do you mean that the problem goes away only for messages that the admin downloads?

If (1), then perhaps it's a problem with permissions in the Registry. I checked and it appears that PocoMail reads values under HKEY_CLASSES_ROOT for file types such as "text" and "html" each time that you click on a multipart message in the Index Pane. On my system, though, all users have read permission to this branch of the Registry but perhaps this is not true on your system? (This seems like an unlikely explanation of the problem, but it's the only one that I've imagined so far.)


This is starting to look like a bug to me.

I would call it frustrating, but I wouldn't call it a bug. As far as I know, PocoMail has never claimed to work in conjunction with Windows' user accounts, although I agree that this would be a very worthwhile goal for the future.
Pete
 

Postby gert » Wed Jul 28, 2004 5:48 pm

Pete wrote:Gert, as I understand things, if he installed PocoMail and all of its data folders under the "Shared Documents" folder, then all users should automatically have read/write access to all of the files and folders. So I agree with you, but I don't think that he should have to explicitly grant any file permissions.


If he changed to a limited account the same way I did previously (over a year ago), by moving the C:\Program Files\PocoMail directory to the shared docs directory, he would need to do this. When those files/directories are moved, XP will keep the original security settings.

Gert
gert
Poco Tourist
 
Posts: 43
Joined: Sun Jul 25, 2004 4:20 pm

Postby waratel » Thu Jul 29, 2004 1:42 am

I thank you guys for your feedback.

To Pete's question, the answer is YES, when I login an admin, or run Pocomail with admin credentials, what I see when I open given emails is different. In other words the behaviour changes with privilege level.

I have checked in Registry for the keys you mention, and certainly, Limited Users only have Read access to these ones. This seems perfectly natural to me, and I can't see why Pocomail should require anything more.

As to Gert's comment re folder ownership, my Pocomail is installed by an administrator account in c:\program files\pocomail3. Within Pocomail, my directories (for mail, attachments, signatures etc) are all pointing to folders under Shared Documents. Thus Pocomail should have unfettered access to the principal data files. However, Pocomail also writes to Poco.ini and other .ini files in its home folder. This can be a problem under Limited User mode, and for this reason I have used CACLS (the 'DOS' equivalent to your suggestion), to grant Limited Users Full access to Pocomail3 and its sub-folders.

Thus my situation is that seemingly all files which Pocomail needs have full access. This leaves a Registry denial, or an unknown file denial as the most likely cause.

Bill
waratel
Drop-in Visitor
 
Posts: 11
Joined: Wed Jul 28, 2004 4:11 am
Location: Melbourne, Australia

Postby Pete » Thu Jul 29, 2004 5:25 am

gert wrote:When those files/directories are moved, XP will keep the original security settings.

This must depend on the version of Windows and/or one's settings. On my system (WinXP Home Edition) and with my settings, copying or moving files into the Shared Documents folders automatically changes the permissions to give everyone "change" permission.

Maybe this behavior is affected by the "Sharing" tab that I see when I select the properties for "C:\Documents and Settings\All Users\Documents". I enable "Share this folder on the network" and I enable "Allow network users to change my files".


waratel wrote:Thus my situation is that seemingly all files which Pocomail needs have full access.

Assuming that file permissions and Registry permissions are okay, I wonder what else it could be. Maybe certain Windows API calls that PocoMail uses are not allowed for Limited Users. If there's any merit to this hypothesis, it might be hard to find the specific unallowed function calls since PocoMail is written in Delphi and thus probably doesn't call most Windows API functions directly.
Pete
 

Postby Sandy » Thu Jul 29, 2004 8:13 am

This whole area of windows permissions is VERY confusing....I know because I once had to spent months unscrambling it for myself (never was able to do that completely until I bought a book and read it throughly).

Pete, you have a couple of misconceptions here (I once had the same ones :wink: )

This must depend on the version of Windows and/or one's settings. On my system (WinXP Home Edition) and with my settings, copying or moving files into the Shared Documents folders automatically changes the permissions to give everyone "change" permission.


Yes and no. What it really depends on is whether you have "simple file sharing" (SFS) enabled or not. Now, in XP-home one does not have the option of turning SFS off; so you, Pete, are stuck with it. With XP-pro and SFS off, it does matter whether a file/folder is copied of moved. Without SFS it works just a Gert said a couple of msgs ago.

Maybe this behavior is affected by the "Sharing" tab that I see when I select the properties for "C:\Documents and Settings\All Users\Documents". I enable "Share this folder on the network" and I enable "Allow network users to change my files".


This is another area of great confusion. Windows has two completely different, but related, systems where the word "permissions" is used: "Share Permissions" and "NTFS Permissions". The kinds of permissions we have been talking about here are NTFS permissions (e.g., read permission, delete permission, execute permission). The Share permissions you mention above are completely different and determine what drives or folders are visible to which userids on the network (note the Share Permissions can not be applied to files at all).
Sandy
 

Postby Sandy » Thu Jul 29, 2004 8:18 am

Another thought.....

Have you ever had a userid (say "Fred"), deleted it, and then recreated it?

This is another area of confusion in NTFS permissions. Everytime a userid is created it is given a unique SID. Even if you later re-create a userid with the same name (e.g., "Fred"), the SID will be different. NTFS permissions are granted to SIDs not to userids. So you can have a situation where it looks like Fred has permission, but that is the "old" Fred not the "new" Fred; and "new" Fred can't access "old" Fred's files.
Sandy
 

Postby waratel » Thu Jul 29, 2004 7:18 pm

Pete wrote:Assuming that file permissions and Registry permissions are okay, I wonder what else it could be. Maybe certain Windows API calls that PocoMail uses are not allowed for Limited Users. If there's any merit to this hypothesis, it might be hard to find the specific unallowed function calls since PocoMail is written in Delphi and thus probably doesn't call most Windows API functions directly.


My Pocomail setup has always had data files stored in Shared Documents, so they weren't moved or copied when I started using Limited User account.

I have now disabled SFS and double checked file access effective permissions for my specific Limited User account, and confirmed Modify access to all Poco data and executable paths. So is there some other path such as in \Windows folder, or registry keys which require Modify privileges for Pocomail??


Sandy wrote:This is another area of confusion in NTFS permissions. Everytime a userid is created it is given a unique SID. Even if you later re-create a userid with the same name (e.g., "Fred"), the SID will be different. NTFS permissions are granted to SIDs not to userids. So you can have a situation where it looks like Fred has permission, but that is the "old" Fred not the "new" Fred; and "new" Fred can't access "old" Fred's files.


I am using NTFS and am aware of SIDs. Recently I did delete unwanted user accounts of type Administrator, Power User, and Limited User. However, the new Limited User account which I created has a distinct name. None of the user accounts deleted ever utilized Pocomail.

Bill
waratel
Drop-in Visitor
 
Posts: 11
Joined: Wed Jul 28, 2004 4:11 am
Location: Melbourne, Australia

Postby Pete » Fri Jul 30, 2004 4:54 am

Bill, to verify that the Limited User has the appropriate file permissions, you could follow these steps:

1) Close all instances of PocoMail (all users).

2) Login as the Limited User.

3) Make a backup copy of In.*

4) Using Notepad or something, change and save each of the files that match In.*

5) If Windows doesn't complain about that, then the Limited User probably has sufficient permissions.

6) Now restore the original versions of In.*

You can repeat the above steps for the INI files in PocoMail's installation folder to verify permissions for those too.

I'm quite sure that PocoMail doesn't write to the Registry or to any other folders during day-to-day operations. You just have to verify that the Limited User has "change" permission (not "modify" permission and not "write" permission) to the files AND FOLDERS (including the topmost folders) in the PocoMail installation folder tree and to each location that you specify in "Options > Directories". The only other location that PocoMail writes to is each user's temp folder, but permissions there should be okay.
Pete
 

Postby Sandy » Fri Jul 30, 2004 7:22 am

You just have to verify that the Limited User has "change" permission (not "modify" permission and not "write" permission)


I don't understand this stmt. "Change" permission grants rights to that SID to change permissions on a file/folder. It has nothing to do with reading/writing/etc the file. I can't see where granting "Change" permission could have anything to do with this, unless you think that either the user or the program is attempting to change the permission configuration on that file (e.g., add write, or remove delete, etc). For an extreme example, if SID had only "change" permission for a file, that SID could not even read the file!

What am I missing?
Sandy
 

Postby Pete » Fri Jul 30, 2004 8:44 am

Sandy wrote:"Change" permission grants rights to that SID to change permissions on a file/folder. It has nothing to do with reading/writing/etc the file.

"Change" permission, by itself, allows the user to read/write the file and some other things. It does not allow the user to change the permissions of the file. To change the permissions of the file, the user needs either "full" permission or he needs to be the owner of the file. So this has everything to do with reading/writing/etc the file. Here's a nice summary of the available permissions if you want to educate yourself:
http://www.winxpsolution.com/ApplyingNTFSXPPro.aspx

---------------------------------------------------------------------------------

Bill, I think that you're okay if you used "Modify" permission. After further research it appears that "Change" and "Modify" mean the same thing in WinXP, except that they are used in different places. Apparently, the cacls.exe program (that I use) refers to it as "Change" permission whereas all of the other documentation that I just read refers to this as "Modify" permission.

So to re-state what I said, make sure that you're using either "Change" or "Modify" permission, but not "Write" permission. "Write" permission is not sufficient because it doesn't allow the user to change part of the contents of an existing file.
Pete
 

Next

Return to PocoMail Help and How-To

Who is online

Users browsing this forum: Google [Bot] and 5 guests

cron