Is there any limit to add users in CLEARCASE_PRIMARY_GROUP?
In Unix/Linux, you can add only up to 32.
Is there any limit on this in windows ClearCase?
According to this IBM article:
ClearCase does enforce a limitation on the number of ClearCase groups a user may belong to.
The SUNRPC protocol that we use can process a maximum of 32 groups on Windows and 16 groups on Unix.
This means that users in an all Windows environment can have a maximum of 32 groups that can use ClearCase and 16 groups in an all Unix environment or a Windows and Unix interop environment.
By default, ClearCase will recognize only the first 32 groups of a user's group list as displayed by the output of the creds utility on Windows.
The total of 32 groups includes the Windows primary group or CLEARCASE_PRIMARY_GROUP variable and the next 31 groups either from the creds output or from the CLEARCASE_GROUPS variable.
The environment variables, CLEARCASE_GROUPS and CLEARCASE_PRIMARY_GROUP, can help to resolve or alleviate some of the issues that may arise due to this limitation.
Related
I am not sure what to make of this weird behavior with generating UUID values. I know uuid_generate_v1() is not as secure as uuid_generate_v4().
We are executing uuid_generate_v1() inside a function to generate a unique Id. Initially when the function was created, it was returning all segments of the uuid populated. I recently needed to create another Azure PostgreSQL instance and was verifying the output and noticed that the last segment of the uuid is now zeros. I re-verified the other Azure PostgreSQL instance we have and they too are now returning the trailing zeroes.
uuid_generate_v4() works fine on all the instances.
I have a version of PostgreSQL 9.6 installed in a docker container on my laptop and it returns all segments populated.
uuid_id
9945111c-b305-11e9-aec6-977857a8b0e6
be647cc2-7cbd-11e9-8498-e7d5a16a0cec
fa1ee220-bf8e-11e9-8b75-000000000000
I am thinking maybe an update was performed, i am not sure where i would check that though.
Hopefully someone might have come across this situation.
Missing MAC address
fa1ee220-bf8e-11e9-8b75-000000000000
That hex string represents the 128 bits of a UUID. Those last twelve hex characters are for the 48-bit node id. For Version 1 UUIDs, node id means the MAC address of the machine generating the UUID.
Most of the other hex characters represent (a) the bits for the value of the current date and time, and the remaining few bits represent (b) a small arbitrary number, and (c) the variant and version of UUID. Those three sources of data are readily available, so no problem there, thus you see the first four segments filled-in.
Likely a bug with Azure
So I would guess you are seeing a bug with regard to Azure failing to report a MAC address for its virtual machines hosting the database.
You are not seeing a problem with Version 4 UUIDs because that version does not use a MAC address. Version 4 uses randomly-generated bits instead, 122 of the 128 bits being random.
You are not seeing a problem on your laptop because your computer (or your Docker container) is properly reporting its MAC address to the Postgres plugin that generates the UUID values.
I suggest you report your experience to the Azure staff as a bug. The Azure folks may not consider it a bug; they might purposely choose to not disclose the MAC address of their server for the security reasons you alluded to in your Question.
I doubt the problem lies with Postgres, the Postgres plugin uuid-ossp, or the well-worn OSSP uuid library contained within the plugin.
Workaround
You might try using a special variation on Version 1 UUID offered by the OSSP library: uuid_generate_v1mc(). This uses a random multicast MAC address instead of the real MAC address of the host computer.
Tip: For testing/debugging, you can simply execute SELECT uuid_generate_v1() ;. No need save to rows and retrieve.
I have a server component that reads its configuration from a file. The configuration file is also read and written by an administration component. The components are separate programs, and they will be running under separate accounts. I want to change the ACL on the configuration file to:
application: read
administration: read and write
Its important to drop write from the application because the application opens a listening socket. That is, its high risk and I want to contain it as much as possible.
After some searching, it looks like ioctl is used to do it in C. ioctl_list offers a list of control codes but its not apparent to me how to add two users with different permissions on the configuration file. The man page online at die.net does not discuss the permissions in-depth or offer sample code. For example the word "perm" (root of "permission") only shows up once in the discussion.
On Windows, reducing permission to honor least privilege is drawn out but its pretty straight forward (Richter gives good examples in his Advanced Windows programming series).
How does one change permissions on a linux file using C APIs? What control codes are to be used?
Thanks in advance.
This is not done with ioctl, but rather with dedicated system calls: chmod, chown, and chgrp for the basic user/group/other set of file permissions, and acl_* for full-fledged ACLs. You probably also want to know about the setuid, setgid, and setgroups system calls, which are how you drop privileges in a running application.
You can accomplish your goals using only the basic user/group/other permissions. Configure your system as follows:
The server application has a dedicated user ID and group; let's say they are both named nlserver ("nl" for "noloader").
The administrative component also has a dedicated user ID and group, let's say nladmin.
The configuration file is set to be mode 0640 (aka -rw-r-----) and owned by user nladmin, group nlserver. (The code responsible for doing this should be in the administrative component, not the server itself.)
When the server starts up, after doing everything it needs to do as root (e.g. bind low-numbered ports), it uses setgroups, setgid, and setuid (IN THAT ORDER!) to change to user nlserver, group nlserver, and clear the supplementary groups list. Only after doing so does it open the configuration file.
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)
My application creates a rudimentary ACL and communicates this to a Kernel Module. The ACL contains a list of UID/GID. The checks on these IDs are custom and on top of what the system already provides.
Now if the root/user changes UID/GID the ACL needs to be refreshed. Is there a way to get notification in an application whenever UID/GID changes e.g. through usermod command? Right now the platform is Linux but we could be porting this to other platforms as well(AIX/Solaris)
I'd say there is no way to reliably detect a change in the UID/Username mapping, especially when you go cross-platform. The user database may reside in NIS, NIS+, or nowadays, LDAP. They might be integrating their UNIX/Linux systems with a Windows Server running Active Directory, or they might be using something more obscure like Hesoid. I know of no way to receive any automatic feedback from these various databases. But also, any good book on UNIX Administration will tell you to not change these mappings, or at the very least, if you must, don't ever re-use a UID. Don't forget, the filesystem whether it's using standard POSIX permissions or POSIX ACLs will also be storing UIDs that won't be getting updates if an Administrator decides to change the UID for a user. The Kernel and filesystem both treat a specific UID as a specific user, regardless of their username. I really don't think you need to bother with the case of an Administrator changing UIDs for a user, it's likely to be too error prone for everyone.
Also, a quick look at NTFS on Windows will reveal that it also stores the equivalent of a UID called SID, it'a a long number used to represent a user and Windows does not provide or expect you to be changing the mapping of that SID to a specific Username. The SID is what the NT Kernel uses internally, not a username. If I open up the Security tab on a file, for a split second I may see numbers until Windows is able to query the Active Directory Controller and give convenient usernames to those numbers. Ultimately, it's the SID, not username that uniquely identifies the user.
On Linux, inotify does what you want. On other systems, try FAM.
One possible way (triggered from Frédéric's reply) is that I could possibly set a inotify/(dnotify gasp! for older kernels) operation on /etc/passwd because that file will always change for at least any change in local user privileges. Trouble is how to do this in NIS environment.
In the typical Unix security model, you should only care about the numerical value for GID/UID, not the mapping between human-readable string and numeric value. As that seems to be the case, have you carefully considered what you are trying to accomplish? Maybe it would be better to pass the name or a name/id tuple, instead of just the id?
I need to write a C program that will allow me to read/write files that are owned by root. However, I can only run the code under another user. I have the root password, but there are no "sudo" or "su" commands on the system, so I have no way of accessing the root account (there are practically no shell commands whatsoever, actually). I don't know a whole lot about UNIX permissions, so I don't know whether or not it is actually possible to do this without exploiting the system in some way or running a program owned by root itself (with +s or whatever). Any advice?
Thanks!
P.S. No, this isn't anything malicious, this is on an iPhone.
Under the UNIX permissions system, you need to run a file owned by root itself that's marked setuid-root (+s, as you said) or communicate with some process that is already running as root.
If there is no such file, you are out of luck.
You can do this with setting suid bit to application, but if you want from this c application run a some shell this was be runned on local user if you do it normally this is security system.
However you can read/write/execute files owned by root, but if your user is not in group of file your target file must have setted read/write/execute on last 3 bits or when your user is in file owner group you must check/apply this to 3 bits in middle position. (3 first bits setting permission to owner but this may not by a usable information for you).
If you dont have any access to root account. Then if group and other user permissions dont access functions as you must have, you can't do with this anything except trying get some prilveaged user for access this file. In other cases you can do some fixes in file access permissions but not from this system, you must get hard drive from this device and attach to other to change it or load on this device some live system to change this. However you can do this on privleaged system not on this.
More information about SUID bits you can find at:
http://www.codecoffee.com/tipsforlinux/articles/028.html
http://www.everyjoe.com/newlinuxuser/explain-what-is-setuid-and-setgid/
The iPhone SDK doesn't allow this. Your application is sandboxed and it is not allowed to go outside of that sandbox except in very specific ways provided by Apple. The only way to do this on an iPhone is to jailbreak it.