rejetto forum

Permission problems in latest betas

Guest · 24 · 27675

0 Members and 1 Guest are viewing this topic.

Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
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?
« Last Edit: September 07, 2008, 08:36:23 AM by TEA-Time »


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13510
    • View Profile
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.
« Last Edit: September 08, 2008, 11:49:32 AM by rejetto »


Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
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


Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
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!
« Last Edit: January 03, 2009, 06:32:25 AM by TEA-Time »


Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
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.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13510
    • View Profile
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


Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
(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.
« Last Edit: January 21, 2009, 04:47:22 AM by TEA-Time »


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13510
    • View Profile

Offline TEA-Time

  • Occasional poster
  • *
    • Posts: 76
    • View Profile
Ah.. so I'm not crazy. :o

Thanks! ;D

Edit: Works correctly in build 220. :)
« Last Edit: January 24, 2009, 06:42:37 AM by TEA-Time »