Re: [OpenAFS] groups in groups, ptsviewers etc...
Marcus Watts wrote: Anders Magnusson <[EMAIL PROTECTED]> writes: Also, for people to be able to see what's in the protection database, they must obviously be members of the (undocumented?) ptsviewers group. Is it safe just to add all people to this group or are there other implications of doing so? Depends on if you ever want private groups or not. If you want everybody in your cell to be able to see group membership by default, you're probably better off running ptserver this way: /usr/afs/bin/ptserver -p 16 -default SOM-- SOM-- probably you will need to remake your ptserver instances in bos to do this. -- Ragge The SOMAR (or "privacy") flags can also be set for individual groups using "pts setfields" if you wish to allow operations on groups x y z but not on the entire PTDB. http://www.openafs.org/pages/doc/UserGuide/auusg008.htm Look for "Protecting Group-related Information" Kim ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] groups in groups, ptsviewers etc...
Anders Magnusson <[EMAIL PROTECTED]> wrote: > What I am thinking on is letting people give access to groups that > they are not member of. > For example to let a teacher give and take rights for courses he > gives; we have about 20k > of (auto-generated) student groups so it's good to be able to list > them to find the right group :-) I would make the teacher the owner of this group in that case and then pts listowned would show it.
Re: [OpenAFS] groups in groups, ptsviewers etc...
Christopher D. Clausen skrev: % pts listentries -groups seems to require that the user belongs to system:administrators. I don't think you realize just how many groups there are in some cells. Enumerating all of them is not useful in many cases. Most users are probably fine just checking on their own group membership and using these groups to allow access to files. pts mem will list the groups that a user is in. And pts listowned will list the groups that a particular users "owns." What I am thinking on is letting people give access to groups that they are not member of. For example to let a teacher give and take rights for courses he gives; we have about 20k of (auto-generated) student groups so it's good to be able to list them to find the right group :-) -- Ragge ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] groups in groups, ptsviewers etc...
Anders Magnusson <[EMAIL PROTECTED]> wrote: > Marcus Watts wrote: >>> Also, for people to be able to see what's in the protection >>> database, they must obviously be members >>> of the (undocumented?) ptsviewers group. Is it safe just to add all >>> people to this group or are there other >>> implications of doing so? >>> >> >> Depends on if you ever want private groups or not. >> >> If you want everybody in your cell to be able to see group >> membership by default, you're probably better off running ptserver >> this way: /usr/afs/bin/ptserver -p 16 -default SOM-- SOM-- >> probably you will need to remake your ptserver instances in bos to >> do this. > As a follow-up to this question, is there a way to allow users to list > the pts entries in some way? Being in system:ptsviewers doesn't help here, as you have probably figured out. You could use something like remctl to allow others to run it via delegated access. Or make modifications to the source code. > % pts listentries -groups seems to require that the user belongs to > system:administrators. I don't think you realize just how many groups there are in some cells. Enumerating all of them is not useful in many cases. Most users are probably fine just checking on their own group membership and using these groups to allow access to files. pts mem will list the groups that a user is in. And pts listowned will list the groups that a particular users "owns."
Re: [OpenAFS] groups in groups, ptsviewers etc...
Marcus Watts wrote: Also, for people to be able to see what's in the protection database, they must obviously be members of the (undocumented?) ptsviewers group. Is it safe just to add all people to this group or are there other implications of doing so? Depends on if you ever want private groups or not. If you want everybody in your cell to be able to see group membership by default, you're probably better off running ptserver this way: /usr/afs/bin/ptserver -p 16 -default SOM-- SOM-- probably you will need to remake your ptserver instances in bos to do this. As a follow-up to this question, is there a way to allow users to list the pts entries in some way? % pts listentries -groups seems to require that the user belongs to system:administrators. -- Ragge ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] groups in groups, ptsviewers etc...
Great, exactly what I was wondering about! Many thanks for your quick answer! -- Ragge Marcus Watts wrote: Anders Magnusson <[EMAIL PROTECTED]> writes: Date:Tue, 18 Mar 2008 10:26:26 BST To: openafs-info@openafs.org From:Anders Magnusson <[EMAIL PROTECTED]> Subject: [OpenAFS] groups in groups, ptsviewers etc... Hi, a few questions for which I don't seem able to find docs :-) It seems like it is possible to recompile 1.4.6 with an option to get the possibility to put groups in groups. - Is this feature considered stable for production use? umich.edu has run with older versions of this feature for ages. Obviously we consider it "ready for production". - Will it allow for multiple levels of groups in groups? Yes. There's a fairly modest depth limit (defaults to 5). - Is this a server-only feature or is the client affected as well (i.e. must the clients be recompiled?) Mostly this affects ptserver. Fileservers and clients do not need to be recompiled. "ListSuperGroups" is an rpc operation which only works on supergroup aware clients, which would affect "ptclient" lsg command and any custom code you wrote that called ubik_PR_ListSuperGroups. For most ordinary purposes you won't need this and can use standard clients. Older versions of openafs only enabled some other useful but unrelated features of pts if you compiled in supergroups support. This should not be an issue with 1.4.6. Also, for people to be able to see what's in the protection database, they must obviously be members of the (undocumented?) ptsviewers group. Is it safe just to add all people to this group or are there other implications of doing so? Depends on if you ever want private groups or not. If you want everybody in your cell to be able to see group membership by default, you're probably better off running ptserver this way: /usr/afs/bin/ptserver -p 16 -default SOM-- SOM-- probably you will need to remake your ptserver instances in bos to do this. -- Ragge -Marcus Watts ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] groups in groups, ptsviewers etc...
Anders Magnusson <[EMAIL PROTECTED]> writes: > Date:Tue, 18 Mar 2008 10:26:26 BST > To: openafs-info@openafs.org > From:Anders Magnusson <[EMAIL PROTECTED]> > Subject: [OpenAFS] groups in groups, ptsviewers etc... > > Hi, > > a few questions for which I don't seem able to find docs :-) > > It seems like it is possible to recompile 1.4.6 with an option to get > the possibility to put groups in groups. > - Is this feature considered stable for production use? umich.edu has run with older versions of this feature for ages. Obviously we consider it "ready for production". > - Will it allow for multiple levels of groups in groups? Yes. There's a fairly modest depth limit (defaults to 5). > - Is this a server-only feature or is the client affected as well (i.e. > must the clients be recompiled?) Mostly this affects ptserver. Fileservers and clients do not need to be recompiled. "ListSuperGroups" is an rpc operation which only works on supergroup aware clients, which would affect "ptclient" lsg command and any custom code you wrote that called ubik_PR_ListSuperGroups. For most ordinary purposes you won't need this and can use standard clients. Older versions of openafs only enabled some other useful but unrelated features of pts if you compiled in supergroups support. This should not be an issue with 1.4.6. > > Also, for people to be able to see what's in the protection database, > they must obviously be members > of the (undocumented?) ptsviewers group. Is it safe just to add all > people to this group or are there other > implications of doing so? Depends on if you ever want private groups or not. If you want everybody in your cell to be able to see group membership by default, you're probably better off running ptserver this way: /usr/afs/bin/ptserver -p 16 -default SOM-- SOM-- probably you will need to remake your ptserver instances in bos to do this. > > -- Ragge -Marcus Watts ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] groups in groups, ptsviewers etc...
Hi, a few questions for which I don't seem able to find docs :-) It seems like it is possible to recompile 1.4.6 with an option to get the possibility to put groups in groups. - Is this feature considered stable for production use? - Will it allow for multiple levels of groups in groups? - Is this a server-only feature or is the client affected as well (i.e. must the clients be recompiled?) Also, for people to be able to see what's in the protection database, they must obviously be members of the (undocumented?) ptsviewers group. Is it safe just to add all people to this group or are there other implications of doing so? -- Ragge ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
