I want to make access polices on the folder each of costumer:
DocumentLibrary/Custumers/CostmerA
DocumentLibrary/Custumers/CostmerA
.
DocumentLibrary/Custumers/CostmerN
Then the CustomerA (tenant user) can't access the folders of other another Customers
I think abut doing this using "Tenants", and a would like to see an exeample.
The Multi Tenant (MT) feature in Alfresco does not do what you ask for. Especially, tenants don't share the same document library, they are completely separated.
You could use MT to achieve complete separation of tenants. This separation would include not only documents but users, groups, permissions, everything you deploy in the Data Dictionary.
I recommend to use a single (default) tenant and normal folder permissions if you just want to handle read/write permissions.
Before using Multi-Tenancy, pay close attention to the features you will be giving up, which are documented here.
The correct way to do what you are attempting to do is to simply use permissions. Give all of your customers access to the /customers folder. Then, in each customer-specific folder, break the ACL inheritance (Manage Permissions, Un-check Inherit Permissions), then assign the specific customer (perhaps using a group) to the folder with the appropriate access.
You might even consider using a separate Share site for each customer, which would make this easier.
The caveat to this is that if you are trying to hide all of your users and groups from each other, then really what you want are separate repositories, and that's what Multi-Tenancy provides, at the expense of the features I referenced at the top of the post.
If you go that route, you'll have to use the tenant console to create each customer-specific tenant. Your tenants will be separated into their own repositories. And you won't have a way to view all of your customer documents side-by-side without switching tenants.
Honestly, due to the stability of the multi-tenancy feature and the other features you have to give up, I'd be more inclined to use completely separate servers, even though that increases your maintenance burden. Alfresco doesn't even use their own multi-tenancy feature in their own cloud product.
You really should have no problems. MT is already there, you just need to enable it. There's no additional work that you should do in order to hide tenants from each others - that's the whole point of this feature.
http://docs.alfresco.com/5.1/concepts/mt-intro.html
I have multiple projects in TRAC. I'm using mod_wsgi, and my wsgi script file TRAC_ENV_PARENT_DIR variable is pointing to the folder containing folders with all these projects. A few users have access to different projects. When a user visits the TRAC URL, she can see the listing containing all these projects, yet has no access to some of them.
Is there any way to show to a user only those projects this user has access to?
Please advise.
Preamble: I abhor security through obscurity. Your request could be read as cosmetics in web site presentation. Don't aim at improved access control, because knowing a valid path will still give access to each Trac environment depending on it's settings. Of course better navigation is a good reason.
Requiring to hide folders depending on user's permission means you require authentication before granting access to TRAC_ENV_PARENT_DIR. This could be done with standard mechanisms that your web server supports. This is just the precondition.
As you say, you have some non-public Trac instances in your Trac environment folder collection. How complicated it is to identify all folders correctly, that depends on how much you want to spend on initial implementation vs. maintenance.
I should be trivial, but error-prone, to provide a list of either the public or the private directories, of course whatever is easier to maintain. Zero additional configuration would require to open each Trac environment and look up user permissions. )** This sounds rather cumbersome and means probably a performance penalty for applications with large user base and frequent access. You will at least work with a cached list, if you go down this road.
You can't use Trac's auto-generated Available projects list but you'll have to deliver at least two versions of an index page for authenticated/unprivileged and authenticated and privileged users.
For the sake of maintenability you'll want to consolitate configuration and permissions. For access to each Trac environment you could use trac.ini inheritance and a shared .htpasswd file. However you can't inherit permissions, because these settings are stored inside the Trac db. You could give TracUserSyncPlugin a shot, but it seems not yet fit for production, or at least lacks feedback of all the happy users, if they exist.
)** While I'm not aware of dedicated documentation about this, there are actually several possibilities. Since permissions are stored in the Trac db, all involve reading/querying the permission db table. It's structure is documented with all other tables of the Trac db schema. To read you'll want to open the Trac environment(s) and then use a direct query on the table (see a AccountManagerPlugin changeset for an example) or construct and query a PermissionCache object.
It may be an old question, but so far i've found the answers to be rather complex without need.
I think using the information stated here, http://trac.edgewall.org/wiki/TracInterfaceCustomization#ProjectList , one could build a template that checks for users and permissions and then show the data it should.
In my case, i just needed to point the "TRAC_ENV_INDEX_TEMPLATE" variable to blank HTML, and that was enough for me.
(I am newbie to tortoise SVN)
I have 2 folders in my tortoise SVN.
Each need a different set of authorization
(I do not want
people who have access to the first folder to have read / write access to the second folder).
How can I accomplish it? I noticed that all permissions are defined in a file in the root level.
This is covered in the Subversion Book section on Path Based Authorization. You can check out the link for more details, but I would just draw your attention to this part:
A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.
Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.
Just to round the post of codeka up. You can't set (at least I never have found out how) any permissions for the repo in tortoise as it is the SVN client application. You would have to set the permission on your svn server. If you happen to be running VisualSVN Server (free) you can setup user rights in a windows-easy manner (point and click).
Should developers have administrator permissions on their PC or is giving them power user access sufficient?
Some comments:
If they want to try out some new
application that would need
installing, then they could try it on
a virtual machine and later get the
network administrator to install it
for them. Do you think that would
work?
Is there anything that a developer
needs to do on their PC that would
require administrator permissions?
We are team of 5 developers and build web applications
The answer is 'Yes'. Developers will need to frig with system configurations to test items, install software (if nothing else, to test the installation process of whatever they happen to be developing), poke about the registry and run software that will not work properly without admin privileges (just to list a few items). There are a host of other tasks integral to development work that require administration privileges to do.
Bearing in mind that development staff do not necessarily have root access to production systems, admin rights on a local PC does not significantly compromise security of production systems. There is almost no legitimate operational reason for restricting admin access to local PCs for staff that need it to do their job.
However, the most important reason to provide administrative access is that setting up a compromised or second rate development environment sends a message to your development staff:
'We value your work so little that we
are prepared to significantly
compromise your ability to do your job
for no good reason. In fact, we are
quite happy to do this to cover our own
arse, pander to the whims of
petty bureaucracy or
because we simply can't be bothered.
That's just the best case. The worst
case is that we're really the
type of control freaks that view it as
our perogative to tell you how to
do your job and what you do or don't
need to do it. Make do with what
you're given and be grateful
that you've got a job at all.'
Generally, providing a second-rate (let alone fundamentally flawed) work environment for development staff is a recipe for the natural consequences of pissing off your staff - inability to retain competent people, high staff turnover, poor morale and poor quality delivery. Going out of your way to do so - particularly if there's an overtone of pandering to bureaucratic whim - is just irresponsible.
Bear in mind that your staff turnover doesn't just incur costs of replacing the staff. The most serious cost of staff turnover is that most of the ones that stick around will be the deadwood that can't get a better job. Over time this degrades the capabilities of the departments affected. If your industry is sufficiently close you can also find yourself getting a reputation.
One point to note is that administrative privileges are far less of an issue for development on unix-oid or mainframe systems than it is on Windows. On these platforms a user can do far more in their own domain without needing system-wide permissions. You will probably still want root or sudo access for developers, but not having this will get underfoot much less often. This flexibility is a significant but lesser known reason for the continuing popularity of unix-derived operating systems in Computer Science schools.
Developers should have full and total control of the machine they are using. Most debugging tools require admin permissions in order to hook into the runtime of the application they are building.
Further, devs frequently download and try new things. Adding additional steps such as needing a network admin to come by and install something for them simply frustrates the dev and will quickly make life hell for the network ops person.
That said, they should be an admin on THEIR box, not the network.
Yes and no.
Yes, it saves lots of time bothering system support.
No, your users don't have it so don't count on it.
We develop with admin permissions and test without. Which works out right.
Local admin yes, for all of the reasons stated above. Network admin no, because they will inevitably be drawn into network administration tasks because "they can". Devs should be developing. Network administration is an entirely different job.
Developers normally need to do things that the average person wouldn't, and so should normally have administrator accounts. Making them hop through awkward hoops wastes their time and demoralizes them. There may be exceptions in high-security situations, but if you can't trust somebody with an admin account you sure can't trust their code.
They should also have an available account of the same permission as their users (more than one account if the pool of users has different permission statuses). Otherwise, they may just develop something cool, deploy it, and then find it won't work for the users.
There are also too many ways to screw up computers with admin accounts (yes, I've done it). The IT department needs a policy that they will re-image a developer's computer if they can't fix it quickly. At one place I contracted at, I had to sign a copy of that policy to get my admin account.
This is a pretty Windows-specific answer. In Linux and other Unix-y systems, developers can more often get by with user accounts only, often don't need another account for test (if they've got an account they can sudo with, they do know when they're using the sudo, but they may need one with the same group permissions), and can do incredible amounts of damage to the OS very easily, so the same IT policy is necessary.
Having endured the pain of having to develop without admin rights on the machine my answer can only be yes, it's essential.
Yes, Half-Life 1 (and all the related mods: counter-strike, day of defeat, etc.) need administrator rights (at least for the 1st run, I think) to work properly in Windows NT, 2000, XP, etc.
And, what kind of developer doesn't play Counter Strike at lunch time? (a crappy one for sure)
Absolutely! How else would I install the download manager to download movies at night?
Sometimes developers really need to install things or change something in the system to test out some idea. It will be impossible if you have to call the admin each time you need to change something.
I also have my personal observation that some admins tend to screw tight all that is possible in order to make even little things depend on them on a daily basis thus... what, securing their job? pissing off the other users? Have no answer. But common sense is not seen here.
Last time there was a problem with my PC I took an active part in restoring the system, making some suggestions working in the team with the admin, or so i thought... Admin turned to be very angry and accused me of trying to teach him or redefine the rules. I suppose it was just his ego as he was not seen that cool in our room among other colleagues.
The answer is, developers should have 2 machines!!
One development one that has admin rights and sufficient power, memory, screen size, and portability, and ADMIN privileges, with corporate antivirus software loaded but configurable by developer when required with autoreset policy..
One corporate one that has corporate load, policies, non-admin user privileges, etc... Developer can use this one for unit testing release mode applications as some developers have the nasty habit of doing all unit testing with administrator privileges.
If you invert the question I think it becomes easier to answer; should we remove administrator permissions from developers? What is the gain?
But actually, I think the answer depends on your context, your environment. Small startup will have a different answer to ISO-certified government agency.
Yes, but they need to be aware of the limitations that their users will face when running software in a more limited environment. Developers should have easy access to "typical" environments with limited resources and permissions. In the past I have incorporated deploying builds to one of these "typical" systems (often a VM on my own workstation) as part of the build process, so that I could always get a quick feel for how the software worked on an end-user's machine.
Programmers also have a responsibility to know the hard-and-fast rules of writing software for non-admin users. They should know exactly which system resources they are always allowed (or forbidden) to access. They should know the APIs that are used to acquire these resources.
"It works on my machine" is never an excuse!
As a systems admin I'm all for developers having local admin rights on their workstations. When possible, it's not a bad idea to do most things with a standard 'user' level account and then use another 'admin' account to make changes, install apps etc. Often you can sudo or runas to accomplish what you want without even logging out. It's also helpful to remind us of what security hurtles the end-users will have to jump through when releasing to production.
On a side note it's also advisable to have a [clean] system or VM(s) so that you can test things properly and not get into the "it looks/works fine on my system" scenario due to system tweaking.
No Power User
First of all, Power User is basically an administrator - so "limiting" a user to Power User does not provide any increase in security to the system - you might as well be administrator.
Log on interactively as a normal user
Second, of course a developer needs administrative access to their developer machine (and servers and second boxes and so on) but of course noone should interactively log on as administrator during normal development or testing. Use a normal user account for this and most applications.
You seriously do not want to run [insert any browser, plugin, IM, E-mail client and so on] as an administrator.
You don't normally log onto your Linux box as root either, even if you likely have root access when you need it.
Use a separate personal administrator account
Provide the developer with a separate personal administrator account to his/her machine (domain account preferably) that is also a valid administrator on other dev/test servers and boxes that person needs administrative access to.
Utilize "run as" and in Vista+ UAC to prompt or request prompt and enter the administrative credentials for tasks and processes only when needed. PKI with smartcards or similar can greatly reduce the strain in entering credentials often.
Everyone is happy (or? ;)
Then audit access. This way there's traceability, and an easy way to find out who is using the terminal services sessions on a particular dev/test server you have to access right now...
Granted, there's definitely development work that will never require local administrator privileges - like most web development where deployment is tested against a separate server or virtual machine and where cassini or whatever is used for local debugging actually runs well as a normal user.
[apologies english is not my mother tongue, doing my best :)]
Well,
Personal experience (I'm a c++/SQL dev):
I used to be admin of my windows machine in my previous job. I also had dbo ( not dba ) rights on databases, including production environment databases. In 2 and a half year with 8 people having these crazy high rights... we never had any trouble. Actually we solved a lot of problems by updating db manually. We could do many things really fast for hot fixes and devs.
Now I changed job. I managed ( crying a lot ) to be admin of my windows machine. But the dev server is a red hat server to which we connect using ssh. Trying to install Qt was a torture, Quota limits, space limits, execution and write rights. We finally gave up and asked the admin to do it for us. 2 weeks later still nothing is installed. I'm getting really fast at newspaper reading and alt+tab hitting.
I asked for admin rights, as only the dev of my soft use this machine.
--> Answer: "If there are processes its for you not to do whatever you want. It has to run fine once in prod".
--> Trying to explain to a non technical manager: "I shall have no admin rights whatsoever in production or UAT environments. But my dev machine is different. If I were to build chairs instead of softwares, would you tell me that I can't put whatever tools I want in my workshop because my workshop needs to look like the place the chair will be used ?
I give an executable package to uat. The libs and tools I used to build them are invisible to the end user or to the dude installing the package."
I'm still waiting today. I found a solution, open a dev environement, go to your favorite online judge, challenge yourself. when somebody look at your screen, he'll be seing you programming. ;)
I work primarily in the *nix world and the standard model there is for developers to work in a normal, non-privileged user account with the ability (via sudo or su) to escalate to admin privileges as/when necessary.
I'm not sure what the equivalent Windows arrangement would be, but this is, in my experience, the ideal setup:
On the one hand, having admin rights available on demand gives the developer full power over his workstation when needed.
On the other, Windows software has a long, long history of assuming that all users have admin rights, to the point that many programs won't run for a non-admin user. Many of Windows' security issues stem directly from this implicit requirement that, in order to be able to reliably use the computer, all users must be admins. This must change and the most effective way to ensure that your software will run for non-admin users is for your developers to be running it themselves as non-admin users.
You can answer this in two ways. Yes and no, or it depends. -- Can I be more vague....
It depends if it is required for them to do their job. If it is then grant them administrative powers over their computer. If not then don't. Not all software development requires an engineer to have admin rights.
Yes and no depends on your view. Some engineers view their computer as their domain and they are the rules of their domain. Others don't want the responsibility.
I have worked at one company where I did not have admin rights and whenever I needed to do something that required admin rights I had to call the help desk and they granted me temp admin rights until I rebooted. This was a pain at times, but that was the way it was so I lived with it. I have also worked at places that I have full admin rights to my computer. This was great except for the time I installed some software that hosed the OS and had to take my computer to the help desk and have them re-image the hard drive....
I personally feel that an engineer should have admin rights to their computer, but with the understanding that if they screw it up then a new baseline image can be reloaded and they will lose anything that was done since the original baseline. I don't believe that everyone in a company should have admin rights to their computer however. Accounting, administrative assistants, and other departments don't really have a need to have those rights so they should not be granted.
https://msdn.microsoft.com/en-us/library/aa302367.aspx
In my experience, a compromise between us (coders) and them (security) is always needed. I admit (though I hate to), there is merit in the Microsoft article above. As I have been a programmer for years, I have experienced the pain where I needed to just install a different debugger, just to get annoyed I can't. It forced me to think creatively in how to get my job done. After years of battling our security team (and several discussions), I understand their job of having to secure all areas, including my desktop. They showed me the daily vulnerabilities that come out, even on the simplest Quicktime app. I can see their frutration everytime I want to install a quick utility or tweak my local IIS that I can cause a serious security problem. I didn't fully understand this until I saw another developer get canned. He was trying to debug and ended up shutting off Symantec only to get (and then GIVE) some virus to hundreds of people. It was a mess. In talking to the one of the "secheads" (security guys) about what happened, I could see he wanted to just say, "told you so...".
I have learned that our secheads (well, at least mine) just want to protect our company. The good news is we did find a compromise, and I can get my job done and the secheads are cool with our secure network!
Creed
Yes if you want the pentesters or some skilled malicious users to get a foothold on compromising your domain.
i.e Compromise low level account > Find where admin -> Mimikatz -> Elevate permissions -> Domain admin.
So no, normal users should not be admins.
Also Microsoft have said UAC is not a security boundary, so don't use it as such. There are various real world bypasses of UAC available.
If they need admin as part of their job role then give out separate domain local admin user accounts used for installing software only (with admin permissions on their own machine only), never for general usage or internet access. This should have a more stringent password policy (eg 15 chars minimum length). Runas functionality should be used for this.
Any environment where normal user accounts are admin is a recipe for a security disaster.
Wow, this question is certainly going to open up to some interesting answers. In reply I quote the oft used - 'It Depends' :)
In small companies this might just be simply a matter of being pragmatic. The developers are also likely to be the most technically adept, so it makes sense for them to adminster their own machines.
Personally, I'm a fan of the "admin account" which can be used when necessary - i.e. "Run As.." (I noticed this approach was very similar in principal to UAC later on).
If you are developing desktop software it's not a bad idea for developers to work within the confines that their end user's will experience - i.e. limited or restricted rights. If you build the software under limited rights, it's a good chance that you'll hit the same problems your target users would face given the same set of permissions.
Having said that, if you have a good testing lab and/or a decent QA team this might be a moot point - especially if you have a half decent ALM practice.
So finally - I develop without UAC, mainly because I trust myself and my skills. In a team environment, I'd put it to a vote. In larger organizations you might not have this freedom.. The Enterprise Admins often have the final say :)
At my company, developers, engineers, and my boss (owner of the company) have local admin privilege. My boss also has network admin privilege, just in case I get hit by that wayward bus (or quit). Everyone else gets locked down.
As sysadmin, this setup has caused me a little grief from time to time, especially when unapproved software gets installed. However, coming from a developer background, I understand the need for power users to have more control over their environment and as such, am willing to put up with the occasional quirk or problem that may surface. I do perform routine backups of their workstations -- just in case.
By the way, I've had more problems with the boss tinkering around with things than with anyone else. Kind of like the old question, "Where does an elephant sit? Anywhere he wants!"
But in a small firm where he is essentially the "backup" sysadmin, there isn't much choice.
It depends on the developer skills and whether s/he is a consultant or not.
I think it's reasonable that a seasoned and trustworthy developer has the rights to do whatever s/he wants with her/his PC as long as it doesn't harm her/his productivity.
No one on Windows XP should be using an administrator account for day-to-day use, and in Vista if you must be an administrator at least have UAC enabled. Especially web developers and other developers who browse the web with Internet Explorer.
What you can do is have developers use their regular user account, but give them a second account that is an administrator on their PC so they can use it as needed (Run As). I know they said web development, but for Windows development your software should be tested using a regular user account, not as an administrator.