rejetto forum

Software => HFS ~ HTTP File Server => Bug reports => Topic started by: TEA-Time on August 18, 2008, 06:02:25 PM

Title: Permission problems in latest betas
Post by: TEA-Time on August 18, 2008, 06:02:25 PM
Hi,

I'm not sure with what beta this started because I only just tried doing this, but the problem exists at least in build 197 and 198.

The setup:
Create a folder (I called it "test") under the root and give an account (I called it "testaccount") permission to only that folder.

The problem:
Try to browse it with http*//server/test and HFS continuously prompts for a login.  The following shows up in the log window:

*****
8/18/2008 10:20:28 AM Server start
8/18/2008 10:42:16 AM 127.0.0.1:1808 Connected
8/18/2008 10:42:16 AM 127.0.0.1:1808 Requested GET /test/
8/18/2008 10:42:16 AM 127.0.0.1:1808 Not served: 401 - Unauthorized
8/18/2008 10:42:16 AM 127.0.0.1:1808 Disconnected by server - 413 bytes sent
8/18/2008 10:42:19 AM 127.0.0.1:1809 Connected
8/18/2008 10:42:19 AM testaccount@127.0.0.1:1809 Login failed
8/18/2008 10:42:19 AM testaccount@127.0.0.1:1809 Requested GET /test/
8/18/2008 10:42:19 AM testaccount@127.0.0.1:1809 Not served: 401 - Unauthorized
8/18/2008 10:42:19 AM testaccount@127.0.0.1:1809 Disconnected by server - 413 bytes sent
8/18/2008 10:42:21 AM 127.0.0.1:1811 Connected
8/18/2008 10:42:21 AM testaccount@127.0.0.1:1811 Requested GET /test/
8/18/2008 10:42:22 AM testaccount@127.0.0.1:1811 Served 885 B
8/18/2008 10:42:22 AM 127.0.0.1:1812 Connected
8/18/2008 10:42:22 AM 127.0.0.1:1812 Requested GET /~style.css
8/18/2008 10:42:22 AM 127.0.0.1:1812 Not served: 401 - Unauthorized
8/18/2008 10:42:22 AM testaccount@127.0.0.1:1811 Requested GET /~style.css
8/18/2008 10:42:22 AM testaccount@127.0.0.1:1811 Not served: 401 - Unauthorized
8/18/2008 10:42:22 AM 127.0.0.1:1812 Disconnected by server - 413 bytes sent
8/18/2008 10:42:22 AM testaccount@127.0.0.1:1811 Disconnected by server - 1298 bytes sent
8/18/2008 10:42:25 AM 127.0.0.1:1813 Connected
8/18/2008 10:42:25 AM testaccount@127.0.0.1:1813 Requested GET /~style.css
8/18/2008 10:42:25 AM testaccount@127.0.0.1:1813 Not served: 401 - Unauthorized
8/18/2008 10:42:25 AM testaccount@127.0.0.1:1813 Disconnected by server - 414 bytes sent
8/18/2008 10:42:27 AM 127.0.0.1:1814 Connected
8/18/2008 10:42:27 AM testaccount@127.0.0.1:1814 Requested GET /~style.css
8/18/2008 10:42:27 AM testaccount@127.0.0.1:1814 Not served: 401 - Unauthorized
8/18/2008 10:42:27 AM testaccount@127.0.0.1:1814 Disconnected by server - 414 bytes sent
8/18/2008 10:42:30 AM 127.0.0.1:1815 Connected
8/18/2008 10:42:30 AM testaccount@127.0.0.1:1815 Requested GET /~style.css
8/18/2008 10:42:30 AM testaccount@127.0.0.1:1815 Not served: 401 - Unauthorized
8/18/2008 10:42:30 AM testaccount@127.0.0.1:1815 Disconnected by server - 413 bytes sent
8/18/2008 10:42:34 AM 127.0.0.1:1817 Connected
8/18/2008 10:42:34 AM testaccount@127.0.0.1:1817 Requested GET /~style.css
8/18/2008 10:42:34 AM testaccount@127.0.0.1:1817 Not served: 401 - Unauthorized
8/18/2008 10:42:34 AM testaccount@127.0.0.1:1817 Disconnected by server - 413 bytes sent
8/18/2008 10:42:36 AM 127.0.0.1:1818 Connected
8/18/2008 10:42:36 AM testaccount@127.0.0.1:1818 Requested GET /~style.css
8/18/2008 10:42:36 AM testaccount@127.0.0.1:1818 Not served: 401 - Unauthorized
8/18/2008 10:42:37 AM testaccount@127.0.0.1:1818 Disconnected by server - 414 bytes sent
8/18/2008 10:42:39 AM 127.0.0.1:1819 Connected
8/18/2008 10:42:39 AM testaccount@127.0.0.1:1819 Requested GET /~style.css
8/18/2008 10:42:39 AM testaccount@127.0.0.1:1819 Not served: 401 - Unauthorized
8/18/2008 10:42:39 AM testaccount@127.0.0.1:1819 Disconnected by server - 413 bytes sent
8/18/2008 10:42:40 AM 127.0.0.1:1821 Connected
8/18/2008 10:42:40 AM 127.0.0.1:1821 Requested GET /~style.menu.css
8/18/2008 10:42:40 AM 127.0.0.1:1821 Not served: 401 - Unauthorized
8/18/2008 10:42:40 AM 127.0.0.1:1821 Disconnected by server - 413 bytes sent
8/18/2008 10:42:41 AM 127.0.0.1:1823 Connected
8/18/2008 10:42:41 AM 127.0.0.1:1823 Disconnected by server - 413 bytes sent
8/18/2008 10:42:42 AM 127.0.0.1:1824 Connected
8/18/2008 10:42:42 AM 127.0.0.1:1824 Disconnected - 1161 bytes sent
8/18/2008 10:42:42 AM 127.0.0.1:1825 Connected
8/18/2008 10:42:42 AM 127.0.0.1:1825 Disconnected by server - 411 bytes sent
*****

From 8/18/2008 10:42:40 AM on down is where I decided to just hit Cancel at the login prompt.
Title: Re: Permission problems in latest betas
Post by: TEA-Time on August 18, 2008, 06:17:25 PM
Oops, I forgot to mention that this does not happen in the latest official release, v2.2d.
Title: Re: Permission problems in latest betas
Post by: rejetto on August 19, 2008, 01:09:33 PM
i just tested, and it worked correctly.
one login, entered username and empty password, and it went ok.
i also tested with a password "a", and all fine again.
are you sure you entered the same password of the account you created?
you can provide your vfs by attaching to the post
Title: Re: Permission problems in latest betas
Post by: TEA-Time on August 19, 2008, 05:52:12 PM
Hi rejetto,

Thanks for the reply!

Sorry, I guess I left something else important out.  My root has restricted access to accounts other than testaccount.  When I leave the root unrestricted or give testaccount access to it, access to /test works fine, but I don't want testaccount to have access to the root.

It seems to me that the css files are coming from the root and are therefore affected by permissions given to the root.

Attached is a very basic vfs with access to the root given to otheraccount and access to the test folder given to testaccount.

Hope this helps, and thanks for looking into it!  Don't feel obligated to spend too much time on it during your vacation. ;)  It's not an emergency or anything.
Title: Re: Permission problems in latest betas
Post by: rejetto on August 21, 2008, 11:03:06 AM
thank you for the vfs, that made things easier.
the problem is actually the css files in the root.
i have no quick solution for it.
maybe i should just unbind template sections from vfs restrictions.
what you think?
Title: Re: Permission problems in latest betas
Post by: TEA-Time on August 21, 2008, 05:14:59 PM
Hi rejetto,

I hope your vacation is going well!

I think unbinding the template sections from VFS restrictions would fix it as long as it doesn't cause a security problem.  Would there be any risks in having unrestricted access to the templates?

What's the different between how v2.2d (which doesn't exhibit this behavior) works and the latest betas?  Were there no css files? ... Ah, I think I just answered that question myself.  I just downgraded to v2.2d and it appears as though the CSS info is embedded in the page, so that explains that.
Title: Re: Permission problems in latest betas
Post by: rejetto on August 31, 2008, 01:22:05 PM
it's not really a security problem, i just thought that someone may want to fully hide the server identity, and accessing resources will tell that it is actually HFS (and roughly the version, at some degree).

for now i will just include the css inside the error pages by using macros. it should work.
Title: Re: Permission problems in latest betas
Post by: TEA-Time on August 31, 2008, 04:53:08 PM
Sounds good to me. :D

Looking forward to the next release!
Title: Re: Permission problems in latest betas
Post by: TEA-Time on September 03, 2008, 05:18:34 PM
Hi rejetto,

I finally got around to testing 201 with this problem and it still exists. :-\
Title: Re: Permission problems in latest betas
Post by: rejetto on September 04, 2008, 08:35:50 AM
mm, i tested it and was fine to me.
maybe you have a customized template.
see if "customized template" appears in the status bar of HFS.
Title: Re: Permission problems in latest betas
Post by: TEA-Time on September 04, 2008, 06:05:39 PM
Hi rejetto,

Nope, no customized template.  Same VFS I posted before, and the same accounts used in it.
Title: Re: Permission problems in latest betas
Post by: rejetto on September 05, 2008, 10:07:28 AM
can you please post the html source you get in your browser when you get the error page?
this is what i get

Code: [Select]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html>
  <head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <style type="text/css">
  body, th { font-family:tahoma, verdana, arial, helvetica, sans; font-weight:normal; font-size:9pt; }
body { background-color:#DDF; padding:10px; }
body, p, form { margin:0 }
a { text-decoration:none;  background-color:Transparent; color:#05F; }
a:visited { color:#55F; }
a:hover { background-color:#EEF; }
img { border-style:none }
#files td { font-size:10pt; background:#FFF; border:1px solid #BBF }
#files td img { vertical-align:top }
#files th, th a, th a:visited { color:#555; font-size:13pt; font-weight:bold; padding-bottom:0; }
#foldercomment { font-size:10pt; color:#888; background:#EEE; padding:3px; border:1px solid #DDD; border-bottom:3px solid #DDD; margin-top:2px; }
#folder, .big { font-size:14pt; font-weight:bold;  }
#folderlabel, #folderstats, #footer { font-size: 8pt; }
#body {
  border-bottom: 4px solid #BBF;
     border-top: 4px solid #BBF;
    border-left: 1px dotted #BBF;
   border-right: 1px dotted #BBF;
  background:#F3F3FF;
  padding:15px;
  margin:15px;
}
.comment { font-size:7pt; color:#888; background:#EEE; padding:3px; border:1px solid #DDD; margin-top:2px; }
.button { height:24px; padding:4px 10px; margin:5px; border:2px solid black; background:white; font-size:8pt; font-weight:bold; }
a.button { padding:8px 10px; }
a.button img { vertical-align:text-bottom; }
.flag { font-weight:bold; font-size:8pt; background:white; color:red; text-align:center; border:1px solid red; }
.item-folder { font-size:smaller; margin-top:4px; }

 
  </style>
  </head>
<body>
<h1>Unauthorized</h1>
This is a protected resource.
<br>Your username/password doesn't match.

<hr>

<div style="font-family:tahoma, verdana, arial, helvetica, sans; font-size:8pt;">
<a href="http://www.rejetto.com/hfs/">HttpFileServer 2.3 beta</a>
<br>05/09/2008 12.07.02
</div>
</body>
</html>
Title: Re: Permission problems in latest betas
Post by: TEA-Time on September 05, 2008, 05:00:31 PM
Hi rejetto,

Here ya go.  Browser cache cleared and everything.  I even created a whole new VFS, and temporarily reset the options.

Code: [Select]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<!-- -->
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <link rel="stylesheet" href="/~style.css" type="text/css">
  <link rel="stylesheet" href="/~style.menu.css" type="text/css">
  <title>HFS /test/</title>
  <link rel="shortcut icon" href="/favicon.ico">

<!--[if lte IE 5.5]>
<style type="text/css">
.menu ul li a, .menu ul li a:visited { width:151px; w\idth:139px; }
</style>
<![endif]-->

 
<style type="text/css"></style>

</head>
<body>
<table width='100%'>
<tr>
  <td width='95%'>
    <div id='folderlabel'>folder</div>
    <div id='folder'><a href="/">Home/</a><a href="/test/">test/</a></div>

<td nowrap>
    <div class='button'><img src="/~img27"> user: testaccount</div>
<td nowrap>
    <div class='button'>
    <form style='width:160px'>
    <input name='search' size='10' value="">
    <input type='submit' value="search">
    </form>
    </div>

  <td nowrap>
    <div class="menu">
    <ul>
    <li class='last'><a href="#"><span style='position:relative; top:5px; left:35px;'>.: Menu :.</span><!--[if IE 7]><!--></a><!--<![endif]-->
    <!--[if lte IE 6]><table><tr><td><![endif]-->
    <ul>



    <li class="last"><a href="/test/?tpl=list&folders-filter=\&recursive">File list</a></li>

    </ul>
    <!--[if lte IE 6]></td></tr></table></a><![endif]-->
    </li>
    </ul>
    </div>

</table>

<div id='body'>
 
  <a class='big' href=".."><img src="/~img14"> UP</a>

  <div class='big'>No files</div>
</div>

<div id='footer'>
  <a href="http://www.rejetto.com/hfs/">HttpFileServer 2.3 beta</a>
  <br>Servertime: 9/5/2008 9:42:20 AM
  <br>Uptime: 00:05:35
</div>

</body>
</html>
<!-- Build-time: 0.130 -->
Title: Re: Permission problems in latest betas
Post by: rejetto on September 05, 2008, 08:47:23 PM
whoops, you are right, i made the wrong test...
Title: Re: Permission problems in latest betas
Post by: rejetto on September 06, 2008, 05:16:55 PM
although i  found possible solutions, i'm studying the problem because it's security sensitive.
in the while, could you please tell me why you need to not give access to the root, to the account who has access to the folder?
Title: Re: Permission problems in latest betas
Post by: TEA-Time on September 07, 2008, 08:24:22 AM
Hi rejetto

Thanks for continuing to look into this!

A friend and I were thinking that it would make sense to be able to give admin type users access to the root and they would automatically be able to browse down through the VFS structure.  Then give restricted users access only to specific lower folders.

Except we actually ran into two problems with trying to do that.

1) The problem you and I are discussing here

2) Permissions given to the root don't automatically flow down (not inherited) if specific permissions are given to lower folders.  It would be cool if there was an option that would allow that if desired, but of course it would be off by default so as not to suddenly change the permission structure of people's existing HFS setups.

I know #2 is actually a request, but I mention it here because it's necessary for what we'd like to be able to do.  If you want, I can add it to the main board, which I guess is where requests/suggestions go..?


Edit: Can't the CSS templates come from the same place the HTML templates do?
Title: Re: Permission problems in latest betas
Post by: rejetto on September 08, 2008, 11:39:09 AM
When you give access to user A to the root, he has access to the folders also.
So permissions are inherited.
When you defining access rights for a folder, why should HFS always give access to A ?
You'll likely have a scenario like:
- home/root access allowed for by A and B
- folder under root allowed to B only

I understand that it will be better to have a dialog where you select accounts for the folder, with A and B already selected, and you remove access for A. Much handier. That's how will be in the future.
Meanwhile you are supposed to give appropriate rights manually.

.........This been said, the problem persists: you can give strange access rights about the root and the folder, and we can suppose you don't want anything to be left out to the public, since we even protected the root.

I had an hard time finding a solution but, perhaps, i did!

if you ask for a folder you have access rights to, then all other files the browser will require from the root will report your folder as referrer.
Then, the root is protected and you don't want anyone to mess around, right?
But we can suppose it's not a big deal if who has access to the folder will access the template sections who appears like files in the root. He will not have access to the root files, but only to sections.

logic: if you have no access for this request, and the request starts with /~ABC, and ABC is a template section, then we'll recheck your access rights against the referring folder (where you are supposed to have sufficient rights).

SO! It should be ok since next beta build.
Title: Re: Permission problems in latest betas
Post by: TEA-Time on September 08, 2008, 05:11:34 PM
When you give access to user A to the root, he has access to the folders also.
So permissions are inherited.
When you defining access rights for a folder, why should HFS always give access to A ?
You'll likely have a scenario like:
- home/root access allowed for by A and B
- folder under root allowed to B only

Just like we're dealing with here. ;)

Quote
I understand that it will be better to have a dialog where you select accounts for the folder, with A and B already selected, and you remove access for A. Much handier. That's how will be in the future.
Meanwhile you are supposed to give appropriate rights manually.

Excellent.  That will work, too.

Quote
.........This been said, the problem persists: you can give strange access rights about the root and the folder, and we can suppose you don't want anything to be left out to the public, since we even protected the root.

I had an hard time finding a solution but, perhaps, i did!

if you ask for a folder you have access rights to, then all other files the browser will require from the root will report your folder as referrer.
Then, the root is protected and you don't want anyone to mess around, right?
But we can suppose it's not a big deal if who has access to the folder will access the template sections who appears like files in the root. He will not have access to the root files, but only to sections.

logic: if you have no access for this request, and the request starts with /~ABC, and ABC is a template section, then we'll recheck your access rights against the referring folder (where you are supposed to have sufficient rights).

Ah.. that sounds like a great solution.  Good job!

Quote
SO! It should be ok since next beta build.

Looking forward to it! ;D
Title: Re: Permission problems in latest betas
Post by: TEA-Time on January 03, 2009, 05:58:29 AM
Hi rejetto,

Sorry to have to dig this bug back up!

I'm using beta build 218 now.  You might want to skim through the previous messages if you need a refresher on what the problem was. ;)

I ran into this problem again using a customized template.  I was using the built-in/default template before and that continues to work.  I just never tried it while using a customized template until now.

The problem appears to be in the way the template folder inherits its permissions from the root.  I can "fix" it by changing the template folder's permissions to give access to "Anyone".  This also allows access by an account that only has permission to folders other than the root, like the situation we worked on before.  Also, doing this allows the template to be used when no anonymous access is given and someone does not successfully log in, by allowing the "Unauthorized" page to look like it's supposed to.

So, I have two questions...

1) Are there any security risks using this "fix"?  I don't know why there would be, but you know a lot more about how things work than I do. ;)

2) If this actually is the proper way to fix this, could you make it so that permission is automatically assigned to the template folder when a customized template is assigned?

Of course, if you have any questions, feel free to ask!
Title: Re: Permission problems in latest betas
Post by: TEA-Time on January 04, 2009, 09:51:46 AM
Ooooops..... :-[  I just realized that this actually has to do with the templates I've been playing with. :-[

RAWR-Template
Terayon
Thunderchicken of Glory

They import their own template folders and set the flags.  Color me embarrassed! :-[ (if you couldn't already tell. heh)  But I am learning! ;D

Anyway, of course it's still necessary for me to change the Access to the templates folder to allow "Anyone" for situations like this thread is about.

So after making this discovery, I checked the wiki and there doesn't appear to be a way using a macro to enable the "Anyone" permission in the Permissions/Access panel.  The same goes for the "Any account" and "Anonymous" permissions.  I would think these would be equally as important as the current ability to assign specific users.
Title: Re: Permission problems in latest betas
Post by: rejetto on January 19, 2009, 03:51:24 PM
you can put these permissions by prefixing the name with @

like @any account
or @anonymous

this is not well documented, i know...
would anyone update the wiki? :D
Title: Re: Permission problems in latest betas
Post by: TEA-Time on January 21, 2009, 04:43:45 AM
(build 219)

Hi rejetto,

I finally got around to trying {.set item|/template|access=@anyone.} and nothing appears to happen.  The same with @any account and @anonymous.  Is that the proper syntax?  Giving access to a specific account with {.set item|/template|access=testaccount.} works just fine.
Title: Re: Permission problems in latest betas
Post by: rejetto on January 23, 2009, 01:44:13 AM
sorry TT, it's a bug.
fixed in next build.
Title: Re: Permission problems in latest betas
Post by: TEA-Time on January 23, 2009, 01:52:36 AM
Ah.. so I'm not crazy. :o

Thanks! ;D

Edit: Works correctly in build 220. :)