> As described, a "role" appears to act essentially the same as a "group"
> - a predefined set of permissions that can be assigned to multiple
> users (as opposed to a set of permissions unique to the user).
[JP]
I should say, the logic of a role is essentially the same as the logic
behind a grou
>
> In this mechanism, does a "role" differ significantly from a "group"?
> I have to admin a CRM system that has both roles /and/ groups, and it
> always seems a bit excessive. But maybe there's some benefit to roles,
> as such, that I'm not seeing.
>
> Thanks, Ben
[JP]
As described, a "role"
From: Ben Dunlap
>> Yes, they offer an additional layer of granularity on permissions.
The apps
>> I write use groups and role to limit acces to certain functionality.
The
>> roles determine functional access to records, ie what the user can do
with
>> them. The groups membership determines what r
> Yes, they offer an additional layer of granularity on permissions. The apps
> I write use groups and role to limit acces to certain functionality. The
> roles determine functional access to records, ie what the user can do with
> them. The groups membership determines what records the user can se
On Aug 27, 2009, at 9:02 PM, Ben Dunlap
wrote:
Sort of. Create two tables a login table with user details and a
specific
field for a ROLE.
Then create a roles table that lists the various permissions. I
store this
[8<]
This process is significantly simpler when managing users, it's
> Sort of. Create two tables a login table with user details and a specific
> field for a ROLE.
>
> Then create a roles table that lists the various permissions. I store this
[8<]
> This process is significantly simpler when managing users, it's easier to
> adjust permissions on one role than to ed
On Aug 27, 2009, at 2:55 AM, "John" wrote:
Hi,
What is the best way to assign permissions to users?
a) Each user has a list of permissions associated with that
user or
Nope
b) Each task/permission has a list of users that qualify or
Nope
c) Have a table w
This is where binary is actually helpful. You can store each
task/permission as a bit, ie, as a yes or no piece of data.
For example: read, write, edit, moderate ... a user with read/write
permissions only would be represented by: 1100, which in decimal is
12. So in effect, you're storing 4 values
Matthew Walker wrote:
And if you're running apache as root, you shouldn't be allowed to.
Apache should always be run as as nonpriviledged user.
On Fri, 2002-09-13 at 09:04, J Smith wrote:
A running script cannot change its own permissions
If you mean can't change it's user ID and/or group ID, that
9 matches
Mail list logo
